Re: [whatwg] allow link in body + DOM position as a rendering hint
Ilya wrote: 1) allow link tags in the body 2) add a note to implementors: consider treating link tags in body as a hint to the UA that what is above the link tag (in DOM order) should not be blocked on painting This seems like a sensible proposal to me. The fact that this just codifies existing browser behaviour (and developer usage) makes it a classic example of paving the cowpaths. To clarify, should the second point (hint to the UA that what is above the link tag should not be blocked) apply specifically to rel=stylesheet, or should it apply to any rel values? (like rel=import that Steve mentioned) Jeremy -- Jeremy Keith a d a c t i o https://adactio.com/
Re: [whatwg] Problems with width/height descriptors in srcset
Simon asked: It also lets us add max-width, though that may complicate the resource choosing algorithm a bit. ~TJ Does doing so solve any use cases? Yes, absolutely. I can go through it all again, but basically having both a min-width/height and a max-width/height option gives the developers the choice of either building in a Mobile First or Desktop First way. i.e. either: Use a small image by default in src and list larger and larger images in srcset or: Use a large image by default in src and list smaller and smaller images in srcset. If you want specific examples of responsive sites currently using one or other of these techniques, I'll be able to find them for you. Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Problems with width/height descriptors in srcset
Odin wrote: img src=small.png srcset=medium.png 800w, small.png 600w, large.png 92000w I really admit that the 92000w looks really ugly. And if you have a viewport that is wider than 92,000 px it will choose the small.png. Maybe it should have a Infinite marker for that case. Can't think of a beautiful solution there. Well, right now the spec text says: omitted width descriptors and height descriptors are considered to have the value Infinity Does that mean I could ditch the 92000w and just leave it blank? img src=small.png srcset=small.png 600w, medium.png 800w, large.png Would that result in this behaviour?: Use small.png unless the viewport is less than infinite pixels wide, in which case use large.png, unless the viewport is less than 800 pixels wide, in which case use medium.png, unless the viewport is less than 600 pixels wide, in which case use small.png after all. I still *must* declare small.png twice (once in src and once again in srcset) but at least I don't have to write an arbitrarily large number for Nw). This still favours a Desktop First approach (where no duplication of image URLs is necessary) but at least a Mobile First approach is possible. Tab wrote: Absolutely agreed. Like several others have suggested, I think we should just go with a min-width:100px approach, which is much clearer. It also lets us add max-width, though that may complicate the resource choosing algorithm a bit. Just to be clear, do you mean changing the syntax so that Nw is replaced with min-width:N? e.g. img src=small.png srcset=medium.png min-width:600px, large.png min-width: 800px or img src=large.png srcset=medium.png max-width:800px, small.png max-width: 600px Those two examples would then be functionally equivalent (give or take a single pixel) but allow developers to take a Mobile First or Desktop First approach according to their preference. Related question: do we still want to keep this unit-less i.e. ditch the px from the examples above? Or, if we're going to use this CSS-like syntax anyway, allow other units of measurement (e.g. ems). Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Problems with width/height descriptors in srcset
I wrote: Well, right now the spec text says: omitted width descriptors and height descriptors are considered to have the value Infinity Does that mean I could ditch the 92000w and just leave it blank? img src=small.png srcset=small.png 600w, medium.png 800w, large.png But I know realise that, according to the spec, I *must* specify at least one value. So actually I'd have to write: img src=small.png srcset=small.png 600w, medium.png 800w, large.png 1x ...which seems to muddy the waters a bit. I actually don't care about the pixel-density of the device in this case, but I need to write 1x because I have to include at least one value. I much prefer Tab's suggestion: I think we should just go with a min-width:100px approach, which is much clearer. It also lets us add max-width I asked: Related question: do we still want to keep this unit-less i.e. ditch the px from the examples above? Or, if we're going to use this CSS-like syntax anyway, allow other units of measurement (e.g. ems). And Tab replied: No, if we're aping the CSS syntax more closely, we should just use CSS units. I agree. Seems like the sensible approach. It also allows authors who are using ems for their media queries in CSS to also use ems for their srcset declarations. Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Defaulting new image solution to 192dpi
Kornel wrote: Note that the scale multiplier can be omitted already when only the size is specified I'm confused by what you mean by scale multiplier. The x value describes the pixel density of the device/screen, not the image, right? Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Features for responsive Web design
Tab wrote: I suspect this is simply confusion about the proposal - @srcset handles the art-directed case same as picture, just with a somewhat more compact microsyntax rather than using MQs directly. You're right. I was thinking that the values (Nh Nw Nx) described the *image* but in fact they describe (in the case of Nh and Nw) the viewport and (in the case of Nx) the pixel density of the screen/device. I suspect I won't be the only one to make that mistake. I can see now how it does handle the art-direction case as well. I think it's a shame that it's a different syntax to media queries but on the plus side, if it maps directly to imgset in CSS, that's good. Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Problems with width/height descriptors in srcset
Simon wrote: The width/height descriptors in srcset seem to be difficult for people to get right, even people who read the spec. * It's not clear from the syntax that it refers to the viewport size rather than the image size. Yes, I made this mistake and so did plenty of others. As Matt Wilcox pointed out, we're used to seeing attributes describe the element they are attached to: not as tests for the viewport/device. * It's not clear if it's min-width or max-width. Yes, right now the spec contradicts itself about this. This will get resolved I'm sure, but I want to discuss what use cases the srcset draft will work for. If I'm taking a Mobile First approach to development, then srcset will meet my needs *if* Nw and Nh refer to min-width and min-height. In this example, I'll just use Nw to keep things simple: img src=small.png srcset=medium.png 600w, large.png 800w (Expected behaviour: use small.png unless the viewport is wider than 600 pixels, in which case use medium.png unless the viewport is wider than 800 pixels, in which case use large.png). If, on the other hand, Nw and Nh refer to max-width and max-height, I *have to* take a Desktop First approach: img src=large.png srcset=medium.png 800w, small.png 600w (Expected behaviour: use large.png unless the viewport is narrower than 800 pixels, in which case use narrow.png unless the viewport is narrower than 600 pixels, in which case use small.png). One of the advantages of media queries is that, because they support both min- and max- width, they can be used in either use-case: Mobile First or Desktop First. Because the srcset syntax will support *either* min- or max- width (but not both), it will therefore favour one case at the expense of the either. Both use-cases are valid. Personally, I happen to use the Mobile First approach, but that doesn't mean that other developers shouldn't be able to take a Desktop First approach if they want. By the same logic, I don't much like the idea of srcset forcing me to take a Desktop First approach. Jeremy P.S. I'm using air-quotes around Mobile First and Desktop First because it's not really about mobile or desktop; it's about small viewports and large viewports but the terms are fairly common. -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Odin wrote: It's heavily optimized for the usecase that will happen most often: for retina type displays: img src=odin-in-suit.jpg srcset=odin-in-s...@2.jpg 2x Okay. This is also what Ted said about the srcset proposal and it makes a lot of sense for that use case. But it seems far less suited to the use-case of art-directed image decisions i.e. allowing the author to specify which image should be displayed (based on some criteria, possibly the viewport size). Jason does a good job of differentiating both use-cases here: http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/ 1. How do we enable authors so that they can display different images under different conditions based on art direction? 2. Enabling authors to provide different resolutions of images based on a variety of conditions. The srcset proposal that has been thrown into the spec looks like a good answer for that second use-case but it doesn't attempt to tackle the first use-case. Now ideally we'd find one solution that solves both use-cases but after the discussion here and in IRC I think that's looking increasingly unlikely. So if we can agree that srcset is a good solution for handling retina displays and other secret sauce conditions (like bandwidth, as Tab blogged about), can we move on to trying to find a different solution for the other use case? I *suspect* that the solution for the art-direction use-case could look almost exactly like media queries (because the use-case is so similar to common use-cases for media queries). Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
The way that datalist is currently designed (and implemented) is exemplary. The fact that (by design) it allows authors to nest a select element within it that shares the same option elements means that authors can safely begin to use this new feature. I've written more about it here: http://adactio.com/journal/4272/ I'm trying (and failing) to understand why Jonas wants this feature removed. Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] The blockquote element spec vs common quoting practices
Bjartur wrote: I'd like to reemphasize that: *unsupported by user agents* So you're saying that because attributes aren't rendered by default, user agents will ignore them and thus we should not use them? It's not a matter of should not. Because user agents ignore them, we *do not* use them. And the main reason why we don't use them is that there's little to be gained: the information isn't presented to the end user. Wishful thinking isn't going to make the @cite attribute any more useful or more widely adopted (either by authors or user agents). Putting attribution inside blockquotes seems like a hack around lax support for attributes. No, putting attribution inside blockquotes solves the real-world use-cases that Oli has gathered together. I'm not sure I understand the question. Do you mean presentational as in not conveying semantics or presentational as in visible? Not conveying semantics. How can you say that the footer element would not convey semantics, when it is defined as follows: 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. —http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-footer-element ...and the blockquote element is a sectioning root. The semantics of those two elements match up perfectly. Interactive user agents should additionally make the cited resource available in manner similar to how they present other hyperlinked resources Can you please give an example of user agents presenting *invisible* hyperlinked resources? @longdesc, perhaps? Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] The blockquote element spec vs common quoting practices
Oli wrote: I’ve outlined the problem and some potential solutions (with their pros and cons) in: http://oli.jp/2011/blockquote/ Excellent work, IMHO. I've added my own little +1 here: http://adactio.com/journal/4675/ Oli continues: I think the blockquote spec should be changed to allow the inclusion of notes and attribution (quote metadata), perhaps by the addition of a sentence like: “Block quotes may also contain annotations or attribution, inline or in an optional footer element” This would change blockquote from being purely source content, to being source content with possible metadata inline or in a footer. However I don’t think that’s a problem, as these things increase the value of the quoted content. I think a spec change is necessary to accommodate common quoting practices. This sounds good to me. 1) Oli has shown the real-world use cases for attribution *within* blockquotes. I know that the Pave the cowpaths principle gets trotted out a lot, but Oli's research here is a great example of highlighting existing cowpaths (albeit in printed rather than online material): http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new. 2) This is something that authors want, both on the semantic and styling level (i.e. a way to avoid having to wrap every blockquote in a div just to associate attribution information with said blockquote). I believe that the problem statement that Oli has outlined fits with the HTML design principle Solve real problems. http://www.w3.org/TR/html-design-principles/#solve-real-problems Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today. 3) The solution that Oli has proposed (allowing footer within blockquote to include non-quoted information) is an elegant one, in my opinion. I can think of some solutions that would involve putting the attribution data outside the blockquote and then explicitly associating it using something like the @for attribute and an ID, but that feels messier and less intuitive to me. Simply allowing a footer within a blockquote to contain non-quoted material satisfies the design principle Avoid needless complexity. http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity Simple solutions are preferred to complex ones, when possible. Simpler features are easier for user agents to implement, more likely to be interoperable, and easier for authors to understand. 4) Because the footer element is new to HTML5, I don't foresee any backward-compatibility issues. The web isn't filled with blockquotes containing footers that are part of the quoted material. Oli's solution would match up nicely with the design principle Support existing content. http://www.w3.org/TR/html-design-principles/#support-existing-content The benefit of the proposed change should be weighed against the likely cost of breaking content Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] The blockquote element spec vs common quoting practices
Bjartur wrote: Citation will most likely contain the cited resource (@cite), the title of the cited resource (@title) and the date and optionally time of the quote (@datetime?). All three of which are invisible and so do not match the use cases that Oli has outlined. At least @title has a tooltip but the @cite attribute has proven to be a complete disaster, unsupported by user agents and ignored by authors, precisely because it is *hidden* metadata. http://www.well.com/~doctorow/metacrap.htm So I think that we can learn from the history of the @cite attribute in that it shows us how *not* to do it. But is it really possible to mark such citations up without presentational elements? I'm not sure I understand the question. Do you mean presentational as in not conveying semantics or presentational as in visible? Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] [br] element should not be a line break
Thomas wrote: What strikes me though is that according to the spec The br element represents a line break. A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation. I agree. Other elements have been redefined to remove medium-specific descriptions from their definitions (b, i, and hr, specifically). It seems logical to me that br should get the same treatment. timeless wrote: The short form is that part of HTML5 is documenting how HTML1..4 works, so that browsers can support existing content by implementing the HTML5 specification. The suggestion, as far as I understand it, is not to change how the element *works* in browsers, but merely to redefine its meaning as a minor logical break rather than a line break. The default browser styling would not change. Aryeh wrote: Anything else is impossible in this case. b and i are also presentational, but the presentation cannot be separated from the semantics. This is no longer true. The semantics of b and i have been changed in HTML5, specifically to separate the presentation from the meaning. Specifically, any reference to screen- or page-specific styling like bold and italic have been removed (allowing the elements to still have meaning in a medium such as audio). I like Thomas's suggestion (or, at least, I like it as much as any of the semantic redefinitions being applied to formerly-presentational elements). The hr element is currently defined as a paragraph-level thematic break. I think br could be defined as a text-level thematic break. Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Content-Disposition property for a tags
Dennis wrote: I have an idea which would be very cool for HTML5. Having a Content-Disposition property on a tags which does the same as the HTTP Header. For example changing the file name of the file to be downloaded or rather have a image file download rather than it being shown in the browser directly. Hang on... isn't the mechanism for this already available via the type attribute? For example: a href=/path/to/image.jpg type=image/jpegFull size image/a A browser could offer a preference setting, for example: Always download the following types of files, rather than opening in the browser: * images[x] * movies[ ] ...etc. -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Content-Disposition property for a tags
Dennis wrote: Yes, but that wouldn't help since I want to force downloads regardless of the browser settings. Ah, I see. In that case, I fundamentally disagree with what you are asking for. Final control should be in the hands of the user, not the author. -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] input type=location proposals
Michelango wrote: 1. Maps are heavy to get, this means UA should heavily cache and/or it should own whole maps data (huge!) 2. If 1) didn't exist because UA can, for instance, get maps data in a blink of an eye: whose data are we gonna use? 3. Maps data are often non-free and non-open, reliable maps data are always non-free and non-open. The second clause of point 3 is demonstrably false. Said demonstration is http://www.openstreetmap.org/ which in many cases (e.g. the town I live in) has better, more up-to-date reliable data than its non-free, non-open counterparts. See also: Wikipedia, blogs, and much of the World Wide Web. (If you hadn't used the word always, I would have let it slide but I cannot bring myself to let such absolutism go unchallenged) My 2c... Seeing your 2c and raising you a citation needed. ;-) But to the point at hand Would the @pattern attribute cover the use case of lat/long inputs? (albeit without a nice UI) Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Microdata feedback
Hixie wrote: Finally on vCard, the final part of the extraction algorithm goes to great trouble to guess what is the family name and what is the given name. This guess will be broken for transliterated east Asian names (CJKV that I know of, maybe others too). Just saying. Also, why is it important to explicitly add N: for organizations? This is intended to be compatible with Microformats vCard, which has these weird rules. If you think we should remove them, please at least first speak to Tantek and see why he thinks. The fn optimisation pattern isn't intended to catch 100% of cases, just the situation Firstname Lastname or Firstname Middlename Lastname. So if you just use fn (formatted name) and don't use n (name), the name will be extracted/guessed using the optimisation pattern. In cases where the pattern doesn't work (e.g. Anne van Kesteren, or east Asian names) you can still explicitly specify the family name and given name, over-riding the fn optimisation pattern. If you do this, you need to explicitly state this is the name (n) as well as the formatted name (fn). Similarly, for organisations, you don't have to explicitly set n (name) if you apply both fn (formatted name) and org (organisation name) to a string. This time, the optimisation pattern assumes that the fn is the name of the organisation. Technically, the n property is *always* required but if you use either of those two optimisation patterns, the n is inferred from fn. HTH, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Use cases for the time element
We seem to be straying behind the bikeshed a little bit here. My point wasn't to point out problems with the examples given in common idioms without dedicated elements http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#conversations The real problem is the definition of the time element itself: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element This sentence: This element is intended as a way to encode modern dates and times in a machine-readable way so that user agents can offer to add them to the user's calendar. ...should be changed to: This element is intended as a way to encode modern dates and times in a machine-readable way. The overly-restrictive clause at the end canonises a single use case as the only usage of the element. The fact that there examples elsewhere in the spec that contradict this definition highlights the problem, but the issue isn't with those examples; it's with the definition of time. HTH, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Use cases for the time element
Henri wrote: On Nov 26, 2009, at 18:50, Jeremy Keith wrote: The following extract shows how an IM conversation log could be marked up. p time14:22/time begof/b I'm not that nerdy, I've only seen 30% of the star trek episodes What's the point of having the time semantically marked up in this example? What kind of processing scenario would benefit? 1. Mashups. A user agent/spider/web service parses the time elements and mashes them up with other timestamped data (photos, status updates, etc.). 2. Graphing. A user agent/spider/web service parses the time elements and generates a graph of activity e.g a sparkline. But the scenario I can't imagine is: a user adds one or all of the events to their calendar. That's why I think it's ridiculous that the *definition* of the time element explicitly states that the purpose of the element is to allow users to add events to their calendar. It's one example of usage. It is not the only possible usage. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On October 14th, Hixie wrote: As far as I can see the options are as follows: 1. Drop support for details and figure for now, revisit it later. 2. Use legend, and don't expect to be able to use it in any browsers sanely for a few years. 3. Use dt/dd, and don't expect to be able to use it in old versions of IE without rather complicated and elaborate hacks for a few years. 4. Invent a new element with a weird name (since all the good names are taken already), and don't expect to be able to use it in IE without hacks for a few years. I am not convinced of the wisdom of #4. I prefer #2 long term, but I see the argument for #3. It looks like the workaround for #3 isn't quite as arduous as it first appeared: http://blog.jeroenvandergun.nl/7-html5-figure-and-details-do-not-break-in-ie Wrapping the details or figure element in a div seems to fix IE's parsing. It's still not ideal but it's much better than the conditional comment object hackery. (and again, this only relates to versions of IE before IE8) So, on balance, #3 is looking more reasonable than #2 (which fails in a lot more browsers). Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
[whatwg] Use cases for the time element
In the section for the time element, the spec states: This element is intended as a way to encode modern dates and times in a machine-readable way so that user agents can offer to add them to the user's calendar. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element It seems very, very restrictive to dictate one single use case for an element. Specifying an example use case, I could understand, but a single use case? Isn't that kind of like dictating a single use for an API before it has even been released? Elsewhere in the spec, this usage is contravened. In the section on common idioms without dedicated elements, this example is given: The following extract shows how an IM conversation log could be marked up. p time14:22/time begof/b I'm not that nerdy, I've only seen 30% of the star trek episodes http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#conversations I think that's a perfectly reasonable use of the time element* but I find it hard to imagine how a user could add a chat message to their calendar. Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ * The example is, however, a terrible use of the b element. The cite element is more appropriate.
Re: [whatwg] fieldset (was: The legend element)
Hixie wrote: Then it might be nice to clarify this with a few words in the spec, as The fieldset element represents a set of form controls optionally grouped under a common name can be read as implying structuring and thus accessibility matters. The element does add structure and help with accessibility, but that doesn't mean it's always necessary. I just had a thought (that I sanity-checked in IRC)... Perhaps fieldset should be a sectioning root? It feels like it's a similar kind of grouping element to blockquote and td in that, while it might well contain headings, you probably wouldn't want those headings to contribute to the overall outline of the document. What do you think? -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Some discrepencies and example remarks
Evert wrote: I am still having problems accepting the differences between section and article though. I understand when to use one over the other, but what was the background for choosing two elements instead of one? What is the drawback of defining just one in the spec (either section or article) and giving that one all the use cases and abilities of the two? I don't see how that would affect anything (not even AT). An excellent question. And I think it's very telling that this overlap is confusing for a working web developer looking at the spec with a fresh perspective. section and article used to be somewhat different. article used to take optional @cite and @pubdate attributes. Now section and article are pretty much identical (the only content model difference being that article may contain a time element with an optional @pubdate attribute). The only semantic difference between the two elements is an adjective: standalone (or independent), which applies to article but not to section ...even though section, by definition, is a collection of related content. The only justification I've heard for the continued existence of two new elements when just one will do, is that it will help authors of blogs from adding class=post to their entries. That is an extremely flimsy justification, one that could be used to justify adding hundreds of new elements to HTML5 (e.g. recipe, comment, story, widget). I'm most puzzled by the cognitive dissonance between the refusal to drop a redundant new element like article, and the refusal at all costs to add new elements where they would be genuinely useful (such as a labelling element for figure and details). -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] article/section/details naming/definition problems
Henri asked: do you think role=article is a legitimate and useful feature in ARIA? Pretty useful but not *as* useful as some of the biggies e.g. search, navigation, contentinfo, and all the roles to do with interaction. Do you accept the notion that ARIA should become syntactically obsolete over time so that its semantics are natively available in HTML proper? (See http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0031.html ) Now that's a big question. :-) If that is the one of the goals of HTML5 then aren't there going to be lots of existing role values that won't be covered by HTML? role=article would probably be the least of them. But, even accepting that ARIA roles should be obsoleted by HTML, that's not the same as being obsoleted by HTML *elements*. It's still possible to specify that a section is of a particular type (e.g. article) without necessarily creating a new element for it. Otherwise we'd have to create password, checkbox, radio elements, etc. instead of using input type=. So an answer of yes to your question doesn't mean that every current ARIA role needs a corresponding distinct element in HTML. Yes. -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] article/section/details naming/definition problems
Lars asked: All articles are sections but not all sections are articles Just to be clear: Does that include the rules for headers when articles are nested, or when an article is contained in a section? Yes, the content model is identical. They are both sectioning content. E.g. would this structure be treated as an identical flow from a headings level perspective if all article tags where replaced with section tags? I.e. Would it be as if I'd use h1, h2 and h3 today? section h1 / article h1 / ... article h1 / /article /article /section Yes. From an outline point of view, this is identical: section h1 / section h1 / ... section h1 / /section /section /section As is this: article h1 / article h1 / ... article h1 / /article /article /article -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] article/section/details naming/definition problems
Divya wrote: this is my understanding of the differences between section and article, forgive me if I am not rigorous in my usage of English: 1. section to cut or section different parts of the layout of the webpage No. This is what div is for. section is for enclosing related content. article is for enclosing related content *that is also independent*. 2. article is used for each similar content, each blog post in a set of (1 or more) blog posts, each user member avatar in a set of user member avatars, each product in a set of products. Not necessarily. If you would use article for a page of 10 blog posts, you should also use article for a page containing only one of those blog posts. The context isn't as important as the content. If the content *could* stand alone, then you are supposed to use article. Whether or not the contact actually *is* standing alone (in the current document) doesn't matter. 3. articles always occur within a section except in rare occasions when there is nothing else other than the specific article on the page as content. No. There is no correlation. * articles do not need to be nested within a section. They can be children of the body element, for example (the body element isn't sectioning content although it is a sectioning root). * articles can be nested within an article. The spec currently advises doing this for blog comments (even though it's questionable whether or not those comments stand alone). * sections can be nested within an article. Different sections of a news story or blog post, for example. * sections can nested within a section. The usecase that leaps to me is: HTML 4: div class=maincolumn div class=item News entry 1 /div div class=item News entry 2 /div /div HTML 5: section class=maincolumn article News entry 1 /article article News entry 2 /article /section This should probably be: div class=maincolumn article News entry 1 /article article News entry 2 /article /div I often use div class=item to mark up the smallest large unit of content that is repeatable and my understanding is that article would be a good replacement of that. Only if the content is independent. Otherwise use div (or section if the content is related). -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] article/section/details naming/definition problems
James Cready wrote: Just curious as to how your above examples would affect SEO. Wouldn't Google lower your rank (even just slightly) because you're using multiple h1 tags? Given Google's support for HTML5, I don't think the new algorithm is going to be a problem for SEO (though I'd welcome clarification on that). Also in this example which header is the most important (for SEO, not just semantics). Is it the first h3 or the first h1? An h1 nested within two sectioning elements has exactly the same importance as an h3. That is, one isn't more or less important than the other; they have an equivalence in importance. -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] article/section/details naming/definition problems
I wrote: An h1 nested within two sectioning elements has exactly the same importance as an h3 Whoops. I was looking at a different example. Ignore what I said and listen to Tab Atkins Jr. -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] article/section/details naming/definition problems
Henri wrote: http://adactio.com/journal/1607/ Ah, you beat me to it. I was just about to write an email to the list, honestly. ;-) So anyway, the upshot of my somewhat unscientific survey[1] conducted at a workshop a couple of weeks ago is that there is great confusion between the section and article elements. In that blog post, I point out that section and article were once more divergent but have converged over time (since the @cite and @pubdate attributes were dropped from article). I've also seen a lot of confusion from authors wondering when to use section and when to use article. Bruce wrote an article on HTML5 doctor recently to address this: http://html5doctor.com/the-section-element/ Probably the best tutorial I've seen on this issue is from Ted: http://edward.oconnor.cx/2009/09/using-the-html5-sectioning-elements ...but even so, the confusion remains. The very fact that tutorials are required for what should be intuitive structural elements is worrying — I don't see the same issues around nav, header or footer (now that the content model has been changed) ...although there is continuing confusion around aside. Anyway... Is there a strong enough case for having two separate new elements or they close enough in functionality that one of them could be dropped? Personally, I don't have a strong opinion about which element name should be dropped, but I do think that dropping one of them would make life easier for authors. Thoughts? [1] Details of the exercise: http://adactio.com/journal/1605/ -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Note on 4.8.7 (video) and 4.8.8 (audio)
Hixie wrote: Fixed. Thanks. Much appreciated. Don't forget to update the note for audio as well as video. Also, with the new wording of the note removing the link to the section on fallback content, it might be a good idea to update the opening of the preceding paragraph from: Content may be provided inside the video element. to: Fallback content may be provided inside the video element. ...with the words Fallback content linking to the relevant section: http://www.whatwg.org/specs/web-apps/current-work/#fallback-content or http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#fallback-content Just a thought. -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Note on the DETAILS element
Hixie wrote; The text for details begins with a definition: I assume you mean the text for hgroup. Doh! Yes, I did. You win some, you lose some, I guess: http://www.brucelawson.co.uk/2009/html-5-is-a-mess/#comment-618892 I've moved the note to an example, so it's less misleading. Thanks, much appreciated. I figured that the genesis of that note was the comment thread on Bruce's post but it only makes sense in the context of H1+H2. Ah well. -- Jeremy Keith a d a c t i o http://adactio.com/
[whatwg] Note on 4.8.7 (video) and 4.8.8 (audio)
I'm finding the wording of the note on the content between opening and closing audio and video tags to be a tad confusing. It reads: In particular, this content is not fallback content intended to address accessibility concerns. This could be interpreted in one of two ways: 1. This content is not fallback content at all. 2. This content is fallback content but it is not the specific kind of fallback content that is intended to address accessibility concerns. I suspect that the second is the intended meaning. If so, then perhaps the note could be reworded to something along the lines of: This content is fallback content. It is not content intended to address accessibility concerns. -- Jeremy Keith a d a c t i o http://adactio.com/
[whatwg] Note on the DETAILS element
The text for details begins with a definition: The hgroup element represents the heading of a section. The element is used to group a set of h1–h6 elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines. But then has this note immediately afterwards: The point of hgroup is to mask an h2 element (that acts as a secondary title) from the outline algorithm. As far as I can tell, this is incorrect. The point of an hgroup is actually to mask *all but one* heading element from the outline algorithm. The note *does* apply to the examples provided: hgroup h1Dr. Strangelove/h1 h2Or: How I Learned to Stop Worrying and Love the Bomb/h2 /hgroup ...but wouldn't be true in this case: hgroup h3Dr. Strangelove/h3 h4Or: How I Learned to Stop Worrying and Love the Bomb/h4 /hgroup In this case, the hgroup element is masking an h4 element (that acts as a secondary title) from the outline algorithm. Even in cases where the hgroup *is* masking an h2, the note would still be incorrect because more heading elements can be hidden from the outline algorithm. e.g.: hgroup h1Dr. Strangelove/h1 h2Or: How I Learned to Stop Worrying and Love the Bomb/h2 h3By Stanley Kubrick/h3 /hgroup The note would make sense if it were moved down to the examples and prefaced with In this case... -- Jeremy Keith a d a c t i o http://adactio.com/
[whatwg] small element should allow nested elements
Hixie wrote: Allowing elements to wrap both inlines and blocks is a huge can of worms which has caused all kinds of problems for ins, del, and a. I really don't want to start adding more elements to this list of complexity. Fair enough. But in that case, I think perhaps the spec could do with a bit of rewording for the small element. The current wording: Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements. ...sounds like an *exact* fit for Remy's use case: So I'm making a list of disclaimers for my site: ol liYou must agree to this term/li liAnd this term too/li liAnd don't break this term/li liAnd don't forget the milk/li /ol pBy reading this, you're agreeing to xyz/p Does anyone have any ideas on a rewording of the definition of the small element to make it clear that it is only intended for certain instances but not others? Alternatively, does anyone else think the small element should be capable of wrapping inline and block elements? (raises hand) -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] A tag for measurements / quantity?
Max wrote: Having used the web for the past 15 years I've always felt that it's a shame when you run into a page with a set of measurements and those can't be interpreted automatically in a sensible fashion. Especially with the fact that there are both imperial and metric units still around in this day and age. There is currently some work going on around measurements over on the microformats wiki: http://microformats.org/wiki/measure If you could share any ideas you have on the brainstorming page, that would be most welcome: http://microformats.org/wiki/measure-brainstorming ...and if you have any examples of markup in the wild, that would be great: http://microformats.org/wiki/measure-examples Hixie asked: I don't really understand the use case here. What problem would this be solving? The problem statement on the microformats wiki page reads: Measures (e.g. weights, sizes, temperatures) occur frequently on the Web, they are constituted of a value a unit-measure and, in scientific and technical contexts, an experimental uncertainty. These 3 elements should be marked-up consistently across websites so that they can be easily identified and acted upon (export, compute, convert) in collaborative distributed applications. Unit-measures differ from locale to locale (e.g. Fahrenheit vs. Celsius, pound versus Kilogram), making comparison and matching of offerings difficult. The measurement microformat will enable unambiguous description of physical quantities and thus provide a solid ground for data sharing and automation in many areas. Max wrote: Personally, the obvious use case for me is recipes. ... With the large majority of humanity doing cooking one could argue that this would be genuinely useful. Then again, it's quite possible no one would ever use this, and it would just end up cluttering the spec. I agree that there is a genuine use case and I also agree that the spec doesn't need to be cluttered with a solution that use case. I think that measurement in general (and recipes in particular) are best solved by microformats and/or microdata. By the way, there is a draft recipe microformat in the works and, once again, your input would be very welcome: http://microformats.org/wiki/hRecipe Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] the cite element
Hixie asked: What is the problem solved by allowing names to be marked up in the same manner as titles? They are both entities being referenced (cited). It seems arbitrary to me to forbid referencing names with the cite element. HTML 4 already allows it, authors would have to change their existing behaviour (something to be avoided wherever possible) and when the meanings of other existing elements—i, b, small—are being *expanded*, I can't follow the logic in *restricting* the meaning of an element already being used broadly. The problem solved by allowing titles specifically to be marked up is that titles are usually typographically offset from the surrounding text in a distinctive fashion. This doesn't apply to names. That's what CSS is for. I haven't changed the spec. I continue to hold the position that covering titles of works is more useful than covering titles of works and names of people, and more useful than covering only names of people or works that are explicitly cited. Okay, but it won't make any difference to authors like myself who will continue to use cite to mark up names. We can do this either by applying a Kenobian interpretation of the spec (e.g. a person is the work of their parents/peers/society and a person's name is therefore a title of work) or we can do it more flagrantly by simply disagreeing with the spec—a precedent for this would be the dl element in HTML4 where the example in the spec showed it being used for dialogue; authors (rightly) ignored the spec. The meaning of the cite element is a classic example of a language feature rather than a platform feature. canvas and video are examples of platform features i.e. features that require work by browser makers to implement. As you have correctly pointed out many times, if browser makers refuse to implement a platform feature, there's no point having it in the spec; the spec would be fiction. When it comes to language features, the browser makers don't have to do much—just make sure the element shows up in the DOM. However, if authors refuse to implement a language feature as described in the spec, then the spec becomes fiction. Platform features need buy-in from browser makers. Language features need buy-in from authors. Authors use the cite element to mark up names. It is often the most semantically appropriate element for marking up a name (and then in itself is a good enough reason to use it—default browser styling doesn't come into it). I don't think it makes sense to ignore the existing behaviour of authors. Authors such as myself will continue to use the cite element to mark up names; our markup will still be conforming; validators won't flag up our choices as errors. Like I said, you can keep the spec as it is if you want but know that that particular part of the spec (detailing usage of the cite element) will be a work of fiction. Eric Vorhes wrote: This isn't about including names of people; that is just the most obvious non-title form of citation. This is about properly understanding what a citation can be and writing the specification for the cite element to account for those possibilities. Citations are references to works, people, etc. By limiting it to title of work you are actually limiting it to a subset of a subset, as many objects worth citing don't have conventional titles. I agree. I don't think the spec should be micro-managing semantic decisions better left to authors. Let me explain with another example I used on IRC earlier... Suppose you're marking up a form. What element do you use to contain your form field and your label? Some authors use divs. Some authors use ps. Some authors use lis. We could argue (we have argued) about which is the most appropriate but in the end, it's the author's choice. Choosing an element to mark up a piece of content isn't always a Boolean proposition. Sometimes there is an obvious correct choice (paragraphs of text should probably be marked up with the p element) but more often than not, different authors will make different choices. And that's okay. Unless it's a flagrant disregard for the semantic meaning of the element (e.g. using the table element for non-tabular content), authors should be allowed to choose what *they* feel is the most semantically appropriate element. I choose to mark up names with the cite element. Other authors choose not to. We will all continue to exercise our personal choices even if the HTML5 spec tries to restrict the meaning of the element. Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
[whatwg] Fwd: Make quoted attributes a conformance criterion
Maciej wrote: So, in conclusion, having a baseline for correct syntax may actually make it easier to develop an ecosystem of style-checking tools. However, this makes it important to keep the core set of syntax errors relatively minimal. I'm not sure HTML5 as currently drafted entirely hits that balance, but mandating optional tags or requiring double quotes on attributes would be a move in the wrong direction. I concur. And I say that as someone who likes the XHTML-like syntax (always closing tags, always quoting attributes, etc.). I don't think my personal preference for writing markup should be enforced in the spec; it should be enforced in the lint tools. The comparison with JavaScript is a good one, I think: JavaScript, C and C++ are examples of languages where conforming syntax is strictly defined, yet tools are available that do additional static analysis for both style and correctness. Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Idea: Links w/o end anchors (is possible)
Darxus wrote; It seems odd to me that the definition of the id attribute doesn't mention its use as a fragment identifier. http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-id-attribute +1 I think it's important to mention the id attribute's relationship to the URI as well to the DOM. Currently the documentation only mentions the DOM. -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Rel and META values
Hixie wrote: 1. Should I change all of the values derived from XFN from proposal to accepted as they seem to fit this criteria? Sure. Done. All we really need is a core group of strong-minded people who are willing to own this problem and maintain this list responsibly (saying no to most proposals, demanding rigorous specs for those they accept, preventing duplicates, documenting existing practices and implementations, etc). ... The community right now is defined as the microformats+w3c communities. I'd like a more dedicated community, but that doesn't just happen on its own -- someone has to step forward and own that process. It's a lot of work, and if we are to have continuity and stability in the process, it would have to be someone willing to commit to this for many years. I'll raise this with the microformats community. While I don't the microformats community itself is the right group for this job, I think that many of the people in the community would be well-suited (and have experience). I'll be sure to make the longevity of committing to a new community process clear. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Rel and META values
Five days ago I wrote: No META value will *ever* become a microformat; the very concept of invisible metadata is anathema to microformats—it's impossible for a META keyword value to pass the microformats process. Should everything on the wiki page be marked as unendorsed or, more realistically, should the conditions for acceptance be altered? I've updated the wiki page for META values, removing the reference to the microformats process. http://wiki.whatwg.org/wiki/MetaExtensions#Process Meanwhile, back on the Rel values wiki page... http://wiki.whatwg.org/wiki/RelExtensions Can anyone help with either of my questions: 1. Should I change all of the values derived from XFN from proposal to accepted as they seem to fit this criteria? 2. I don't think passing the buck to the microformats community is necessarily a good idea. There are perfectly good values listed (e.g. rel=accessibility) that would/should probably never become a microformat but are still good semantic values. Will they really be rejected outright? Thanks in advance, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] the cite element
Chris wrote: If more then titles means other uses of the CITE tag, as evidenced in [1], they do not form any pattern. They look more like random errors. I've used the CITE element fairly extensively on my blog, *mostly* for titles (books, films) but also for people. If it's a proper noun, then it could potentially be marked up using CITE, IMHO. -- Jeremy Keith a d a c t i o http://adactio.com/
[whatwg] Rel and META values
I'm a bit confused by the conditions set out at the bottom of the rel extensions wiki page: http://wiki.whatwg.org/wiki/RelExtensions For the Status section to be changed to Accepted, the proposed keyword must either have been through the Microformats process, and been approved by the Microformats community; or must be defined by a W3C specification in the Candidate Recommendation or Recommendation state. If it fails to go through this process, it is Rejected. 1. Should I change all of the values derived from XFN from proposal to accepted as they seem to fit this criteria? 2. I don't think passing the buck to the microformats community is necessarily a good idea. There are perfectly good values listed (e.g. rel=accessibility) that would/should probably never become a microformat but are still good semantic values. Will they really be rejected outright? Then there's the wiki page for META values: http://wiki.whatwg.org/wiki/MetaExtensions For the Status section to be changed to Accepted, the proposed keyword must either have been through the Microformats process and been approved by the Microformats community; or must be defined by a W3C specification in the Candidate Recommendation or Recommendation state. If it fails to go through this process, it is Unendorsed. This is kinda nuts. No META value will *ever* become a microformat; the very concept of invisible metadata is anathema to microformats— it's impossible for a META keyword value to pass the microformats process. Should everything on the wiki page be marked as unendorsed or, more realistically, should the conditions for acceptance be altered? -- Jeremy Keith a d a c t i o http://adactio.com/
