[whatwg] ins, del, and mark crossing element boundaries
Keryx Web wrote on 26/03/08 08:44: ... This is from Thomas Thomassen on WSG's list: As I was working on this I wanted to mark up a list where items had been added and removed. That's when I realised that you can't wrap up li dt or dd in del or ins elements because ul, ol and dl only allows list items as their direct child. ... Oh, but it's even worse than that. :-) ins, del, and mark are the three cases I can think of where the appropriate content model could be described as roughshod -- there's no logical reason (other than ease of implementation) for any of them to fit neatly inside the element hierarchy of the rest of the document. For example, a couple of lines of an ancient poem might be interpolated by an editor where insects had eaten away at the original manuscript, and those insects had paid no attention to the HTML element hierarchy: p ...br ...br ...br ins... /p p ...br/ins ...br ...br ... /p Similarly an editor might insert extra sentences into the middle of a paragraph, and therefore split the paragraph in two to prevent it being over-long: p...ins.../pp.../ins.../p. Conversely, she might remove text from two adjacent paragraphs, and therefore collapse them into a single paragraph: p...del.../pp.../del.../p. And a highlighted portion of an essay or article can easily include multiple paragraphs, and/or a whole paragraph plus part of an adjacent paragraph. p...mark.../pp.../pp.../p/mark The real-world things that the ins, del, and mark elements represent can all cross element boundaries at will, just like the text selection in a Web browser can. But with the current (and all previous) content models for these elements, those effects need to be faked using multiple elements. I don't know what use this observation is. Maybe it means ins, del, and mark shouldn't be HTML elements, but should be something else instead. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] ins, del, and mark crossing element boundaries
Matthew Paul Thomas wrote: I don't know what use this observation is. Maybe it means ins, del, and mark shouldn't be HTML elements, but should be something else instead. Excellent post. I have to add that from a Wysisyg editor's perspective, and I said it many times in the past, ins and del are almost the only elements that are intrinsicly block-level AND inline-level. In other terms, if you select the whole text inside a paragraph and remove it, it is pdelfoo/del/p or delpfoo/p/del ? Discrimination is impossible, it's a nightmare. /Daniel
Re: [whatwg] ins, del, and mark crossing element boundaries
On 2 Apr 2008, at 12:43 pm, Daniel Glazman wrote: Matthew Paul Thomas wrote: I don't know what use this observation is. Maybe it means ins, del, and mark shouldn't be HTML elements, but should be something else instead. Excellent post. I concur. Excellent summary of how these elements are not hierarchical, but overlaid over the content of the document. The only way I can see to have these in a well-formed DOM is by using empty elements for both the start and end. p…ins-start/…/pp…ins-end/…/p However, that said, I believe more strongly that the ins, del and mark are metadata about the document, not specifically *part* of the document, and as such, perhaps they need to be moved completely out of flow, either into the head or into an auxiliary metadata file. They are seldom used AFAICT, not being mentioned on [1], and I think there is a valid reason for this lack of use which should be addressed. Are the elements necessary in HTML, should the information they convey be specified in another manner completely? [1] http://code.google.com/webstats/ — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] ins, del, and mark crossing element boundaries
Nicholas Shanks wrote: The only way I can see to have these in a well-formed DOM is by using empty elements for both the start and end. p…ins-start/…/pp…ins-end/…/p Right. Coming from the SGML world, that's called paired elements and they're usually linked through id and idref. That's how a range should be represented and a single selection is a range. However, that said, I believe more strongly that the ins, del and mark are metadata about the document, not specifically *part* of the document, and as such, perhaps they need to be moved completely out of flow, either into the head or into an auxiliary metadata file. They are seldom used AFAICT, not being mentioned on [1], and I think there is a valid reason for this lack of use which should be addressed. Are the elements necessary in HTML, should the information they convey be specified in another manner completely? Managing that in an editor would be a true nightmare. Please, please, please no. /Daniel
Re: [whatwg] ins, del, and mark crossing element boundaries
I agree, very insightful post, MPT. You cut to the true issues quicker than we were doing earlier. ^_^ Nicholas Shanks, you may well be right. ins/del/mark (idm) are a form of embedded metadata, but how would we extract such out of the html flow? This isn't metadata about the document, after all, but about particular pieces of content within the document. You can't even use the dom to target it, since, as noted, idm properly aren't hierarchical and can cross dom boundaries. I like the paired-elements proposal, much better than my earlier ideas of being able to wrap li/li in idm. It gives you all the power of idm while retaining a well-formed dom tree. However, it's not ideal. The stuff in the range is no longer targetable with CSS, frex. We could poke at CSS3 to have a new pseudo-element set for idm, but meh. How do implementors feel about this? ~TJ On Wed, Apr 2, 2008 at 8:05 AM, Nicholas Shanks [EMAIL PROTECTED] wrote: On 2 Apr 2008, at 12:43 pm, Daniel Glazman wrote: Matthew Paul Thomas wrote: I don't know what use this observation is. Maybe it means ins, del, and mark shouldn't be HTML elements, but should be something else instead. Excellent post. I concur. Excellent summary of how these elements are not hierarchical, but overlaid over the content of the document. The only way I can see to have these in a well-formed DOM is by using empty elements for both the start and end. p…ins-start/…/pp…ins-end/…/p However, that said, I believe more strongly that the ins, del and mark are metadata about the document, not specifically *part* of the document, and as such, perhaps they need to be moved completely out of flow, either into the head or into an auxiliary metadata file. They are seldom used AFAICT, not being mentioned on [1], and I think there is a valid reason for this lack of use which should be addressed. Are the elements necessary in HTML, should the information they convey be specified in another manner completely? [1] http://code.google.com/webstats/ — Nicholas Shanks.
Re: [whatwg] Video
On 2 Apr 2008, at 4:53 pm, Krzysztof Żelechowski wrote: Dnia 01-04-2008, Wt o godzinie 23:38 +0100, David Gerard pisze: The actual solution is a large amount of compelling content in Theora or similar. Wikimedia is working on this, though we're presently hampered by a severe lack of money for infrastructure and are unlikely to have enough in time for FF3/Webkit/HTML5. I tried converting Flash to Ogg and the resulting file was five times larger. Chris Err, yeah. Don't do that :-) Transcoding from one lossy format to another is a sure way to increase file size and decrease quality. Re-encode it into ogg from the source material, and make sure your ogg exporter settings are apropriate for the delivery medium you want. — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] INS and DEL in lists
Dnia 28-03-2008, Pt o godzinie 13:29 -0500, Tab Atkins Jr. pisze: On Fri, Mar 28, 2008 at 12:07 PM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: Dnia 28-03-2008, Pt o godzinie 09:12 -0500, Tab Atkins Jr. pisze: And the original problem can be solved using CSS2; I only wanted to bring a similar example: HTML poorly supports interleaving unrelated markup streams. Please, elaborate. The reason this is a problem is because it *can't* be well-solved with CSS. How about LI CLASS=DEL ? Conveys no semantics, unfortunately. Non-css browsers will have no way of knowing that this is a deleted item. That's the whole point of having a del element in the first place. On the other hand, mixing together lists and tables doesn't seem to have any good semantic interpretation. How about bilingual lists that have to be aligned in two columns? The reason I objected to that example was because you'd pretty much just be jacking the *display* of ol for your own purposes, without regard to the semantics. If you just want something numbered without giving it proper list semantics, hand-number it or use generated content. On the other hand, once I have a list, I can put it into a table cell. Then I translate the list into the neighbouring cell and I realise that the translations do not align. According to your recipe, I have to convert the original list structure to something else, something that older browsers do not support well. I feel frustrated about that. Ah, so in *this* case you're actually hijacking the *table* display while ignoring semantics. You could just use a table to display it (I think the semantics would probably be okay). If you want the list semantics specifically, use a *single* list and wrap each translation in a container that you can then give a defined width so that they stack next to each other. That's just the first thing that came to mind. The most attractive feature of HTML to me is that it does not say Resolution 800×600 required — indeed, there are products that require it without saying, which is even worse. I am worried such an explicit layout would make the text unreadable on lower resolution displays and hard to read on higher resolution displays. And moreover, merging the lists is breaking them because either uses a different numbering style because they are in different languages. Chris
[whatwg] Video
I wrote: From my perspective, and for what it's worth, I doubt that the ideals of the W3C as expressed in 3.12.7.1 http://3.12.7.1 would result in a situation that would be superior to simply letting the international standards body for audio and video codecs deal with these technological areas. Gervase Markham wrote: Your plan would, at least, prevent the standard codec being supported on Free operating systems. Meeting 3.12.7.1 as it stands would not prevent this. Therefore, it would be a superior situation. David Gerard wrote: The actual solution is a large amount of compelling content in Theora or similar. Wikimedia is working on this, though we're presently hampered by a severe lack of money for infrastructure and are unlikely to have enough in time for FF3/Webkit/HTML5. - d. It will be very, very difficult to develop critical mass for content encoded in Theora (or Dirac), much less ubiquity. I'm not saying there's no point in trying. I applaud the effort, though I have misgivings about the W3C setting itself up as a video/audio standards organization when we already have the Motion Picture Experts Group. But ... why not recommend that web developers encode in MPEG-4 AVC or Theora? At least that would give some direction out of the current morass. ISO/IEC standards, like AVC/h.264, are vastly preferable to single-vendor (non)standards from Adobe, MS and Real. Why should the W3C choose not create a better situation than the current one (which is a mess for developers and a mess for users), while continuing to work on the ideal? Robert J Crisler
Re: [whatwg] ins, del, and mark crossing element boundaries
Nicholas Shanks wrote: Hi Daniel. You've obviously had these issues on your mind a long time. Oh, 16 years only... :-) What is the benefit of the @start attribute on the ending tag? Shouldn't the @end attribute be sufficient. I fear that if you let HTML authors loose with something like this they'll end up with mis-matching pairs, and while still able to create those (e.g. two start tags ending at the same ID; or pointing to non-extant IDs) the surface area for error is greater if the end tag has to be the inverse of the start tag too. Yes, the end attribute is enough to style data. Having cross-links between the elements is really helpful for instance when you place the caret right after the end tag, move the caret to the left to reach that end tag, and you want to offer the possibility to cancel the deletion of that portion of text. Retrieving the start tag is then easier than a dom traversal... But I see your point about possible mismatched pairs. /Daniel
Re: [whatwg] Video
On 2 Apr 2008, at 16:55, Robert J Crisler wrote: It will be very, very difficult to develop critical mass for content encoded in Theora (or Dirac), much less ubiquity. I'm not saying there's no point in trying. I applaud the effort, though I have misgivings about the W3C setting itself up as a video/audio standards organization when we already have the Motion Picture Experts Group. I don't think anyone whatsoever is suggestion to create a new codec — we'd gain nothing by doing so. But ... why not recommend that web developers encode in MPEG-4 AVC or Theora? MPEG-4 has patent fees to be paid, making it impossible for Firefox or Konqueror (for example) to comply to that. Theora has unknown patent status, and big companies are unwilling to implement it (as it has little pre-existing content, and it is no better than what they already have) lest they get sued due to some submarine patent. At least that would give some direction out of the current morass. ISO/IEC standards, like AVC/h.264, are vastly preferable to single- vendor (non)standards from Adobe, MS and Real. All the codecs that have publicly been looked at already have glaring issues with actually getting them interoperably used. We need something everyone is willing to implement. If people don't implement what we say, what we say is irrelevant. Why should the W3C choose not create a better situation than the current one (which is a mess for developers and a mess for users), while continuing to work on the ideal? There's a reason why the status quo is the status quo: different people willing to implement different things. One standard cannot force people to implement something they don't want to. We cannot just create a better situation: people have to actually do what we say to be in any better situation than we already are. One group can't implement specifications with known patents, and the other is unwilling to implement specifications with no known patents, due to submarine patent risks. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Video
Dnia 02-04-2008, Śr o godzinie 10:55 -0500, Robert J Crisler pisze: Why should the W3C choose not create a better situation than the current one (which is a mess for developers and a mess for users), while continuing to work on the ideal? With all due respect: the mission of the WWW Corporation is to create standards, not to create situations. Situations are usually created by large companies and sometimes by user communities. Chris
