[whatwg] Why isn't the pattern attribute applied to input type=number?
Regarding the an input with type in the number state, the spec states
that the pattern attribute must not be specified and do[es] not
applyhttp://dev.w3.org/html5/spec/common-input-element-attributes.html#do-not-apply
to
the element. (
http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#number-state-type-number
)
Why is it specifically blocked? Doesn't that encourage the use of a less
semantic text input type for numbers that need to be validated beyond
simple max and min?
What if you want the number to be either 13 or 16 digits long, as with a
credit card
pattern=(\d{5}([\-]\d{4})?)
or you want a US ZIP or ZP4 code which can either be n or n-
pattern=(\d{5}([\-]\d{4})?)
To get the pattern to validate, I have to (non-semantically) change the
input to the text state? I much prefer the current behavior of Firefox
(tested 9 and 10) which does validate the pattern.
Brenton Strine
Re: [whatwg] Why isn't the pattern attribute applied to input type=number?
Hi Brenton,
On 02/10/2012 11:39 AM, brenton strine wrote:
Regarding the an input with type in the number state, the spec states
that the pattern attribute must not be specified and do[es] not
applyhttp://dev.w3.org/html5/spec/common-input-element-attributes.html#do-not-apply
to
the element. (
http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#number-state-type-number
)
Why is it specifically blocked? Doesn't that encourage the use of a less
semantic text input type for numbers that need to be validated beyond
simple max and min?
What if you want the number to be either 13 or 16 digits long, as with a
credit card
pattern=(\d{5}([\-]\d{4})?)
or you want a US ZIP or ZP4 code which can either be n or n-
pattern=(\d{5}([\-]\d{4})?)
To get the pattern to validate, I have to (non-semantically) change the
input to the text state? I much prefer the current behavior of Firefox
(tested 9 and 10) which does validate the pattern.
Using input type=number for those cases is wrong. You would not use a
credit card number or a ZIP code in calculations. (In fact, in the
United Kingdom, post codes contain letters.)
input type=number is meant to be used for numbers, rather than for
strings that happen to contain mostly numbers. The specification does
indeed require a *more* semantically correct input type=text for those
cases.
The reason that Firefox validates the pattern is that it currently does
not implement input type=number (patches welcome). Instead, it
implements the fallback behaviour defined in the specification, i.e.,
treat unknown 'type' values as 'text'—which causes the pattern attribute
to apply. Using input type=number pattern=... will break as soon as
Firefox correctly implements the feature.
HTH
Ms2ger
Re: [whatwg] Why isn't the pattern attribute applied to input type=number?
2012-02-10 12:39, brenton strine wrote:
Regarding the an input with type in the number state, the spec states
that the pattern attribute must not be specified and do[es] not
apply to the element.
That’s because the pattern attribute is for constraining text data using
a regular expression.
Why is it specifically blocked? Doesn't that encourage the use of a less
semantic text input type for numbers that need to be validated beyond
simple max and min?
A regular expression, which operates on texts, is not a _logical_ way to
set constraints on _numbers_. A number is a mathematical entity; a
numeral, such as 2000 or 2.000 or 2,000 or MM, is a textual presentation
of a number.
At a more concrete level, type=number really means type=spinbox, but
modern design of markup languages favors names that look more semantic.
(If type=checkbox were invented today, it would probably be called
type=boolean.)
What if you want the number to be either 13 or 16 digits long, as with a
credit card
pattern=(\d{5}([\-]\d{4})?)
Then you use type=text. Whether the value is a number or just a
sequence of digits is debatable. But in any case you don’t want to
create a spinbox.
Yucca
Re: [whatwg] Quirks Mode Standard
On 2/10/12 2:57 AM, Simon Pieters wrote: 1) I'm fairly certain the Images (img elements) without alt attributes sometimes display placeholder icons in quirks mode. quirk cannot be dropped. ... The HTML specification specifies this quirk in the Rendering section. http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#images-0 Ah, excellent. ;) 4) The CSS parsing quirks need to define behavior for shorthands. Other than the behavior for 'font' (assuming 'font-size' is on the list), what's missing? (My idea was that shorthands that reference other properties (or value productions from other properties) in their Value: specification would automatically support unitless lengths, e.g. 'background' where only position gets rewritten to use quirklength because 'background-position' is in the list but 'background-size' is not.) I agree that having the list for lengths reduces the scope of the problem somewhat. But the color quirk means that any shorthand that includes colors will run into ambiguity issues if any keywords for any subproperty only use letters in the range a-f. I _think_ we can't hit that case now, but going forward that will either place a restriction on keyword values or we'll need to define how to resolve the ambiguity somehow. Even for lengths, if we ever add any new subproperties to border, say, that happen to take numbers we would run into trouble. I'd rather not overconstrain future development of CSS by how we define quirks behavior. So I would prefer to avoid the problem as Gecko does, frankly. Of course I'm biased. ;) This discussion is probably worth taking to www-style. It's interesting that 'font-size' is not in the list I trusted https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior which says The CSS parser interprets unitless numbers as px (except for font-size because that was what Netscape Navigator 4 did :-) Huh. That's a blatant lie! I fixed the page. Now added, but I'm not sure right now how to spec how the 'font' shorthand is handled. Exactly. My proposal, again, is that neither of these quirks apply inside a shorthand. -Boris
[whatwg] [Cross-document messaging] Restrictions on targetOrigin
Hi. Step 1 of the spec [1] for postMessage says: 1. If the value of the targetOrigin argument is neither a single U+002A ASTERISK character (*), a single U+002F SOLIDUS character (/), nor an absolute URL, then throw a SyntaxError exception and abort the overall set of steps. The absolute URL part will create problems when the origin of the scripting environment does not serialize to an absolute URL. For instance, if you have two documents A and B in a non http context, where typically the origin will be null, like file: or data:, and post a message from A to B, B will receive a message event which event.origin property has a value of null. If the listener then does # event.source.postMessage(reply, event.origin) (which is a code snippet easily found in online tutorials) step 1 causes that call to fail with a SYNTAX_ERR exception. Step 1 should be changed to instead of referring to an absolute URI, refer to a valid origin, as serialized by the origin serialization algorithm. Thoughts ? [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#posting-messages
Re: [whatwg] Quirks Mode Standard
On Fri, Feb 10, 2012 at 10:37 AM, Boris Zbarsky bzbar...@mit.edu wrote: I agree that having the list for lengths reduces the scope of the problem somewhat. But the color quirk means that any shorthand that includes colors will run into ambiguity issues if any keywords for any subproperty only use letters in the range a-f. I _think_ we can't hit that case now, but going forward that will either place a restriction on keyword values or we'll need to define how to resolve the ambiguity somehow. Even for lengths, if we ever add any new subproperties to border, say, that happen to take numbers we would run into trouble. I'd rather not overconstrain future development of CSS by how we define quirks behavior. Why not just say that these quirks only apply to existing syntaxes, not new ones? I was quite surprised to find that unitless numbers worked for 'transform-origin' in quirks mode.
Re: [whatwg] Quirks Mode Standard
On 2/10/12 11:23 AM, Aryeh Gregor wrote: On Fri, Feb 10, 2012 at 10:37 AM, Boris Zbarskybzbar...@mit.edu wrote: I agree that having the list for lengths reduces the scope of the problem somewhat. But the color quirk means that any shorthand that includes colors will run into ambiguity issues if any keywords for any subproperty only use letters in the range a-f. I _think_ we can't hit that case now, but going forward that will either place a restriction on keyword values or we'll need to define how to resolve the ambiguity somehow. Even for lengths, if we ever add any new subproperties to border, say, that happen to take numbers we would run into trouble. I'd rather not overconstrain future development of CSS by how we define quirks behavior. Why not just say that these quirks only apply to existing syntaxes, not new ones? Simon's proposal does that, but it's not good enough to avoid all the problems. For example, border-bottom-width is in the list of properties that has the quirk apply to it, as is border-bottom. If we add a border-bottom-count property for some sort of multiple border setup and allow setting it via border-bottom, then you suddenly have a parsing ambiguity for border-bottom, right? -Boris
Re: [whatwg] RWD Heaven and responsive-images
The above is just a my proposal in advancing this discussion, and until there is no feedback about this from people on the RWD Heaven: if browsers reported device capabilities in a request header and the add html-attribute for responsive images threads, and other developers concerned in Responsive Web Design, I don't think I should just create the group and hope that the discussion will just move and concentrate there on its own. So open for feedback on this! Kind regards to all, Viktor I’m certainly not opposed to a more productive venue for hashing out some of these issues, but I still worry that we’re backtracking. We’ve already covered a lot of the same ground on this list as a large group of us did months ago ( https://etherpad.mozilla.org/responsive-assets is one of many venues in which this took place ). While I’m in no way railing against having a bunch of new eyes on this problem and new potential solutions, I’m afraid of going back and rehashing the same ideas for the sake of people just joining the conversation. By the time we reach a conclusion—possibly the same conclusion—and present it to the list again, who’s to say we wouldn’t find ourselves repeating the process all over again? Basically, I’d want to ensure that any discussion within the group takes place in a very public and easy-to-digest way, so we have an easy reference for people joining the conversation late in the game. I’d also love to see a representative from each of the big browsers and a couple of people close to the standards process directly involved, so we can stay as focused and productive as possible. I’m happy to reach out to people, to those ends. Any way you slice it, you’re right that this list isn’t the place for continued discussion of this sort. Viktor, if you’re willing to set up such a group, that’s probably a more appropriate venue—at least for the time being.
[whatwg] Character-encoding-related threads
On Mon, 6 Jun 2011, Boris Zbarsky wrote: You can detect other effects by seeing what unescape() does in the resulting document, iirc. Doesn't seem like it: http://junkyard.damowmow.com/499 http://junkyard.damowmow.com/500 In both cases, unescape() is assuming Win1252, even though in one case the encoding is claimed as UTF-8. As well as URIs including %-encoded bytes and so forth. In both cases here, I see URLs getting interpreted as UTF-8, not based on the encoding of the containing page: http://junkyard.damowmow.com/501 http://junkyard.damowmow.com/502 Also you can detect what charset is used for stylesheets included by the document that don't declare their own charset. My head hurt too much from setting up the previous two tests to actually test this. There are probably other places that use the document encoding. Worth testing some of this stuff I'm happy to consider specific tests. Currently however, it seems like Firefox is the only one with any kind of magic involved in determining the encoding of javascript: URLs at all, and that magic doesn't seem to have as many side effects as one would expect, so I've left it as is. On Wed, 30 Nov 2011, Faruk Ates wrote: My understanding is that all browsers default to Western Latin (ISO-8859-1) encoding by default (for Western-world downloads/OSes) due to legacy content on the web. But how relevant is that still today? Has any browser done any recent research into the need for this? I'm wondering if it might not be good to start encouraging defaulting to UTF-8, and only fallback to Western Latin if it is detected that the content is very old / served by old infrastructure or servers, etc. And of course if the content is served with an explicit encoding of Western Latin. That is in fact exactly what the spec requires. The way that we detect that the content is very old / served by old infrastructure is that it lacks a character encoding declaration... :-) On Wed, 30 Nov 2011, L. David Baron wrote: I would, however, like to see movement towards defaulting to UTF-8: the current situation makes the Web less world-wide because pages that work for one user don't work for another. I'm just not quite sure how to get from here to there, though, since such changes are likely to make users experience broken content. One of the ways I have personally been pushing UTF-8 in the specs is by making new formats only support UTF-8. On Thu, 1 Dec 2011, Sergiusz Wolicki wrote: I have read section 4.2.5.5 of the WHATWG HTML spec and I think it is sufficient. It requires that any non-US-ASCII document has an explicit character encoding declaration. It also recommends UTF-8 for all new documents and for authoring tools' default encoding. Therefore, any document conforming to HTML5 should not pose any problem in this area. The default encoding issue is therefore for old stuff. But I have seen a lot of pages, in browsers and in mail, that were tagged with one encoding and encoded in another. Hence, documents without a charset declaration are only one of the reasons of garbage we see. Therefore, I see no point in trying to fix anything in browsers by changing the ancient defaults (risking compatibility issues). Energy should go into filing bugs against misbehaving authoring tools and into adding proper recommendations and education in HTML guidelines and tutorials. Indeed. On Fri, 2 Dec 2011, Henri Sivonen wrote: On Thu, Dec 1, 2011 at 8:29 PM, Brett Zamir bret...@yahoo.com wrote: How about a Compatibility Mode for the older non-UTF-8 character set approach, specific to page? That compatibility mode already exists: It's the default mode--just like the quirks mode is the default for pages that don't have a doctype. You opt out of the quirks mode by saying !DOCTYPE html. You opt out of the encoding compatibility mode by saying meta charset=utf-8. Quite. On Mon, 5 Dec 2011, Darin Adler wrote: On Dec 5, 2011, at 4:10 PM, Kornel Lesiński wrote: Could !DOCTYPE html be an opt-in to default UTF-8 encoding? It would be nice to minimize number of declarations a page needs to include. I like that idea. Maybe it's not too late. Just configure your server to send back UTF-8 character encoding declarations by default, and you don't need to think about it. On Wed, 7 Dec 2011, Henri Sivonen wrote: If you want to minimize the declarations, you can put the UTF-8 BOM followed by !DOCTYPE html at the start of the file. That is indeed another terse solution. On Mon, 5 Dec 2011, Sergiusz Wolicki wrote: As far as I understand, HTML5 defines US-ASCII to be the default and requires that any other encoding is explicitly declared. I do like this approach. It's important not to confuse the default for authors (which is indeed ASCII) and the default for browsers (which is a complicated answer, but which defines the processing for bytes
Re: [whatwg] Using footer in blockquote for attribution
On Fri, 1 Jul 2011, Oli Studholme wrote: Over at http://html5doctor.com we�ve been using this pattern when quoting e.g. from the HTML5 spec: blockquote p[block quote]/p footer� citea href=�[title of work]/a/cite/footer /blockquote I wrote about our use of blockquote and footer in http://html5doctor.com/blockquote-q-cite/ recently, which lead to http://www.w3.org/Bugs/Public/show_bug.cgi?id=13082. To recap: Footer definition: �The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.� Blockquote definition: �The blockquote element represents a section that is quoted from another source. Content inside a blockquote must be quoted from another source, whose address, if it has one, may be cited in the cite attribute.� Simon felt that �Content inside a blockquote must be quoted from another source� excludes footer. On what basis? However the footer definition reads to me that footer is basically metadata *about* content (the non-footer or -header content of the sectioning or sectioning root element). I�m happy to propose some reasons for allowing this, but to start with does blockquote�s definition beat footer�s definition? Or, is footer considered content as far as the blockquote definition is concerned? Content in a blockquote is quoted. This includes any footers in it. For example, a page might say: article h1My Opinion/h1 pBla bla bla./p pBla bla bla./p pAnd furthermore, I think fish are friends, not food./p footer pFred is a shark./p /footer /article Another page might then quote that page: pBut the best part is the end, where Fred writes:/p blockquote cite=http://fred.example.net/blog/my-opinion; pAnd furthermore, I think fish are friends, not food./p footer pFred is a shark./p /footer /blockquote pNotice the footer saying that he's a shark! Sharks emlike/em to eat fish, surely./p It's not clear to me why or how the spec is ambiguous here. I've not added this specific example to the spec, but I've added unambiguous requirements regarding attribution. On Fri, 1 Jul 2011, Simon Pieters wrote: Indeed since it's a conformance requirement, in valid documents the content inside blockquote is quoted from another source. If the spec were to allow attribution inside blockquote, the above conformance requirement would need to be changed to allow it. Indeed. On Tue, 5 Jul 2011, Jukka K. Korpela wrote: I was pretty sure that I had seen an example where a blockquote element contained an attribution in a footer. Alas, the “living standard” does not seem to have a version history where I could conveniently check this out. You can see all versions of the spec ever published using the Subversion repository. See the spec header for tools for accessing it. Admittedly, there is some logic in requiring that the content of blockquote be quoted from an external source and nothing more. I wonder whether this disallows common constructs like “[foo]” to indicate that “foo” has been added for clarification and is not present in the source. I've addressed this. Anyway, having a blockquote element but no markup for attribution is very illogical. Indeed. We may fix this in due course. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Allow Fallback Text to Render Section Titles in Outlines
Currently when I run markup like this through outliner programs, they return blank section titles: h1img src=/img/logo.png alt=Company Name //h1 h1 svg g titleCompany Name/title path / … /g /svg /h1 I feel that in both instances, Company Name should become the section title for the respective section. Yes, I could use CSS image replacement to work around this issue, but that is a hack—it isn't semantically accurate as the image is not a decorative background, but in fact a important piece of content which should still appear with CSS off. Similarly, repeating the alternative text outside of the image and hiding it with CSS would be redundant, both visually and to screen readers, with CSS off. I could also use CSS @font-face rules to embed the logo font and just use text, but not all fonts have licenses that permit doing so; many explicitly forbid @font-face linking or specify that only graphical renderings are allowed. I also often receive fonts from clients that have modified letterforms, but have not been made into general-use fonts, which makes embedding impossible. So, text-as-graphics, while not ideal, is sometimes the only option. Since both img and svg fall under h*’s content model (phrasing content), it only makes sense to allow their fallback text to be used as section titles. This would aid accessibility and meet author expectation—in addition to mine, see for instance this person, who filed it as a bug under a particular implementation: http://code.google.com/p/h5o/issues/detail?id=5#c0.
