[whatwg] Semantic markup for buzzwords
This is a proposal for semantic markup in HTML5. Problem statement: Modern web pages, especially those written for marketing purposes, often include so-called buzzwords, or trend-leveraging verbal tokens. Markup for them is needed both to achieve distinct visual rendering and to emphasize them for search engines. Despite the need for specialized semantic markup, currently no such markup exists, and authors use ad-hoc presentational markup for buzzwords. Proposed solution: Redefine the existing deprecated presentational element B to mean a buzzword. Keep existing default style (font-weight: bold) associated with it. With such formatting, buzzwords will visually stand out on the page, allowing the reader, such as a prospective VC evaluating an IT project proposal, to briefly skim through a web page picking out only buzzwords. Advantages: * The solution is backward compatible with existing browsers which already implement distinct rendering for B. * The practice of using B to mark up buzzwords is already widely adopted. * Some search engines rank words marked up with B higher than the rest of the text. * B is a nice single-letter tag name that would be sad to waste as an obsolete element. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://my.opera.com/feldgendler/
Re: [whatwg] Semantic markup for buzzwords
On Tue, 01 Apr 2008 18:08:20 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: I believe the current definition of the B element allows for such use: http://www.whatwg.org/specs/web-apps/current-work/#the-b The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is boldened. This describes b as a presentational element, but my proposal makes it semantic. On Tue, 01 Apr 2008 18:05:44 +0200, Brian Kardell [EMAIL PROTECTED] wrote: Can you please explain precisely how this would differ from strong which really should work exactly as you described? Is it really mostly just the fact that some search engines don't accurately respect strong as being the essential equivalent of b? If so, then I would like to suggest that this might not be the best solution, and that suggesting some alternative tag for semantics isn't probably going to help solve this problem in any meaningful way since the recommendations that we have around now have been available for search engines to figure out and implement for longer than some of the engines themselves. Could you not achieve what you are looking for with meta tags or some alternative means? Using a different tag name would suffer from the chicken-and-egg probem, and the advantage of b is that it's already widely used for exactly the purpose proposed. Just my 2 cents for what they are worth. Also - it is very possible that I don't understand, if so could you expand? Taking into account the very special date on which this discussion is happening should clarify matters. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://my.opera.com/feldgendler/
Re: [whatwg] additional key attribute in form field
On Fri, 06 Jul 2007 13:32:17 +0200, Alexander [EMAIL PROTECTED] wrote:
i wonder why there's still no a special 'key' attribute for every form
field implemented.
Let's say I have rendered table from query result and one column could
be updateable via text field.
And let's say record id field is uniqueidentifier (not integer). I'd
like to write the following:
form ...
!--- Loop query results ---!
input type=text key={id_value_here} name=quantity value=
input type=text key={id_value_here} name=quantity value=
!--- End of loop ---!
/form
and
when submitting the form and checking results on server, I'd like to
know the 'owner' of every quantity field:
!--- loop via quantity fields ---!
if (quantity.key == '----') { ... }
!--- end of loop ---!
The simple name/value pairs that form submission is organized in are
sufficient for expressing data structures of any complexity.
Multidimensional keys like (name, key) in your example can be expressed
through combined names:
input type=text name=quantity:{id_value_here} value=
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] additional key attribute in form field
On Fri, 06 Jul 2007 14:07:10 +0200, Alexander [EMAIL PROTECTED] wrote:
The simple name/value pairs that form submission is organized in are
sufficient for expressing data structures of any complexity.
Multidimensional keys like (name, key) in your example can be expressed
through combined names:
input type=text name=quantity:{id_value_here} value=
Of course, it's how I usually do this :) But I would not be against some
common specified approach - especially taking into consideration some
restriction on 'name' symbolset (there are much less restrictions on
'value' symbolset)
Changing the form submission formats (that currently only allow for
name/value pairs) is out of scope for WHATWG.
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The problem of duplicate ID as a security issue
On Fri, 08 Jun 2007 08:13:07 +0200, Ian Hickson [EMAIL PROTECTED] wrote: True. I don't have a good solution to this that doesn't involve code on the server-side, though. Some form of sandboxing would be one. If sandboxing would solve it then I'll treat this issue as closed and deal with the sandboxing problems separately. Only some form of sandboxing would solve this, not any form. To solve this issue, the sandboxing solution has to meet additional an requirement: addressability of content in sandboxes, possibly using a qualified form (e.g. URL#sandboxID+innerID). -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The problem of duplicate ID as a security issue
On Thu, 07 Jun 2007 00:42:31 +0200, Ian Hickson [EMAIL PROTECTED] wrote: IDs in user-supplied content are only useful as fragment identifiers for URLs, and mangling them like that defeats this use case because you don't know N before you post the comment, and therefore can't make internal links within the body (and it's also unobvious when you try to make links to parts of your article afterwards). True. I don't have a good solution to this that doesn't involve code on the server-side, though. Some form of sandboxing would be one. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The problem of duplicate ID as a security issue
On Thu, 07 Jun 2007 00:20:18 +0200, Ian Hickson [EMAIL PROTECTED] wrote: Preventing such attacks by a HTML cleaner would require either making a full list of all forbidden IDs, class names etc, or imposing Draconian rules upon user-supplied content, completely disallowing such useful attributes like id and class. I'm not really convinced there's that much use in user-supplied IDs and classes, but the rules needn't be that draconian. The server could automatically prepend the commentN string to IDs and classes. IDs in user-supplied content are only useful as fragment identifiers for URLs, and mangling them like that defeats this use case because you don't know N before you post the comment, and therefore can't make internal links within the body (and it's also unobvious when you try to make links to parts of your article afterwards). -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Drop UTF-32
On Mon, 04 Jun 2007 12:34:56 +0200, Henri Sivonen [EMAIL PROTECTED] wrote: Including it in a few encoding detection algorithms is no big deal on us implementers: as the spec stands we aren't required to support it anyway. All the spec requires is that we include it within our encoding detections (so, if we don't support it, we can then reject it). What's the right thing for an implementation to do when UTF-32 is not supported? Decode as Windows-1252? Does that make sense? Seems like a general question: what's the right thing to do when the document's encoding is not supported? There isn't a reasonable fallback for every encoding. Also, even for those encodings for which a single-byte encoding like Windows-1252 can be a reasonable fallback, it's doesn't seem wise to me to mandate the use of Windows-1252 (or any other fixed encoding) as the fallback. Some software, especially in devices, already exists that only supports one or several encodings, and these are the most important ones in the local market (e.g. Japanese in devices sold in Japan). -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Drop UTF-32
On Mon, 04 Jun 2007 15:15:06 +0200, Henri Sivonen [EMAIL PROTECTED] wrote: I think it is perfectly reasonable to make support for UTF-8 and Windows-1252 part of UA conformance requirements. After all, a piece of software that doesn't support those two really has no business pretending to be a UA for the World Wide Web. Not supporting Windows-1252 based on local market arguments is serious walled- gardenism. On the other hand, declaring Windows-1252 as the default encoding is monoculturalism. For example, in Russia, whenever Windows-1252 is chosen, it is definitely a wrong choice. It's never used in Russia because it doesn't contain Cyrillic letters. A default of Windows-1251 or KOI8-R might be reasonable in Russia, though none of them is a 100% safe guess. This is to say that there shouldn't be any mandated fallback encoding. Whenever a fallback encoding is needed, it should be taken from the user preferences or vendor presets which are likely to reflect the most popular encoding in the area. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] [WF2] Clear On Focus attribute
On Wed, 23 May 2007 02:31:38 +0200, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: You need a label for the field... but don't want to put one beside it. So the label goes inside the field... until you click on it. (At which point the label disappears.) The field's value shouldn't be abused to achieve this effect because the label is not a value. Stylesheets should be used to get a semantically appropriate piece of information, such as the field's title, to display in the box when the field is empty and has no focus. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] [WF2] Clear On Focus attribute
On Wed, 23 May 2007 19:02:26 +0200, Charles Iliya Krempeaux
[EMAIL PROTECTED] wrote:
The field's value shouldn't be abused to achieve this effect because the
label is not a value. Stylesheets should be used to get a semantically
appropriate piece of information, such as the field's title, to display
in the box when the field is empty and has no focus.
It's true that web developers probably should not be doing this.
(Since it messes up semantics.) But they are.
So... perhaps we can come up with a way for them to get this effect,
while preserving semantics.
Maybe a new attribute? innerlabel maybe... or something like that.
So, maybe something like
input type=search innerlabel=search in vancouver...
Innerlabel smells a bit of cellspacing and bgcolor. The fact that
the label is inner shouldn't deserve a separate way of expression in
markup.
My point is that it's CSS, not HTML, that should be extended to make it
possible to put the label inside the input. Something along the lines of:
input[value=]:not(:focus) { content: attr(title) }
(Currently that would completely replace the input field with static text,
without any chance of focusing the control. Probably there should be
something better than the content property. CSS3 is definitely going to
offer something here.)
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] password option for window.prompt?
On Tue, 22 May 2007 17:38:28 +0200, Lee Kowalkowski [EMAIL PROTECTED] wrote: I'm more against allowing javascript: URIs in the HTML source, they should only be allowed via JS DOM operations to reinforce progressive enhancement practice. While it would be nice if HTML documents didn't contain javascript: URIs, in practice they already do, and we'd gain nothing by declaring this illegal. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Sandboxing ideas
On Tue, 15 May 2007 13:02:51 +0200, Gervase Markham [EMAIL PROTECTED] wrote: I'd treat these two problems as equally important. A separate HTTP request per forum comment on the page is completely unacceptable. Would you really want separate security contexts for each comment? I wouldn't want to allow people screw up others' comments, making it look that other users wrote what they didn't write. So, yes, it's important that any code within a comment cannot change anything but itself. This also means that the comment should be unable to change the header/footer around it to pretend that someone else wrote it. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] meter: unbounded values
On Tue, 15 May 2007 20:11:21 +0200, Elliotte Harold [EMAIL PROTECTED] wrote: This may have already been asked (sounds familair) but I don't see it in the archives. What if the min or max values for a meter is unbounded? For example, the 7th member of the Fibonacci series? How does one indicate that? Why do you think meter is approrpiate for indicating such a value? The whole idea of a meter (I mean, an instrument, which this English word means) is to visualize some quantity by displaying it in comparison with a reasonable upper bound. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Sandboxing ideas
On Tue, 15 May 2007 23:37:37 +0200, Jon Barnett [EMAIL PROTECTED] wrote: The OP probably meant that maintaining so many contexts would cause a comparable deterioration in performance. All user comments should be put in one security context. With all comments grouped together in such a manner, you could even use an inline frame. I really think comments are a bad use case. Why would someone allow scripts in comments in any context, much less a sandboxed one? Sure, comments are probably an unrealistic example. But embedding widget-like scripts in blog entries is, I think, realistic. The best use case I have thought of so far is MySpace et. al., a site where users have their own page with limited permission in the context of the overall site. MySpace solves this by not allowing scripts at all, as most such web sites do. If possible, such sites might allow a user to insert widget scripts with limited permissions. For this use case, iframe isn't ideal, either, but limited scripting and styling are desired. There are contexts in which blog entries by multiple users are displayed in one page (aggregation contexts like LiveJournal friends pages). Technically this is equivalent to the example with comments: units of content authored by different users needs to be protected from each other. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Sandboxing ideas
On Tue, 08 May 2007 18:46:10 +0200, Henri Sivonen [EMAIL PROTECTED] wrote: Kind of like an iframe but without an external source. My understanding is that main issue with iframe isn't the external source but that the view port establishment. I'd treat these two problems as equally important. A separate HTTP request per forum comment on the page is completely unacceptable. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Sandboxing ideas
On Mon, 14 May 2007 22:02:42 +0200, Jon Barnett [EMAIL PROTECTED] wrote: I'd treat these two problems as equally important. A separate HTTP request per forum comment on the page is completely unacceptable. What about encoding the content of each comment iframe in a data: URI? The contents of an iframe with a data: URI source should be trusted, unlike an iframe with an http: URI source from another domain. A script in an iframe with a data: URI source should, by default, be able to communicate with the parent window. So, that alone doesn't solve the problem. Not to mention that data: URIs are ugly, wasteful (because of the BASE64 encoding), cannot be read and written by humans directly, and have maximum length problems in some implementations. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Sandboxing ideas
On Mon, 14 May 2007 22:29:57 +0200, Michel Fortin [EMAIL PROTECTED] wrote: I was pointing out a solution for the problem of separate HTTP requests on a forum page. Used in conjunction with some previously-suggested security attributes on iframe, it could do a pretty good sandbox for use comments on a page. If you want the sandbox to degrade securely in older browsers, then this is not a solution. Yes, I want the sandbox to degrade securely, as does any webmaster who might be going to allow some user-supplied scripting while relying on sandboxing for security. To cover its use cases, this feature must degrade securely. But I don't think there's a nice solution to that anyway. This does degrade securely, doesn't require separate HTTP requests, and maintains human readability. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2005-December/005301.html However, I admin that it's not quite “nice” (as in “æsthetics”). -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Sandboxing ideas
a part of the page it's hosted in, but we want to sandbox it to make sure it can't do any harm. Let's say we'd like to sandbox anonymous user-contributed comments on a blog, but not comments from logged in users. That would require all anonymous comments to be placed within an iframe. For 100 anonymous comments, that's 100 iframes on a single web page. Don't tell me that's an elegant solution. Why not? Or rather, why is a 100 sandbox frames (or whatever) better? 1. Because it doesn't require 100 HTTP requests to load the page. 2. Because it doesn't require a separate domain to serve the iframe content from. These two are major, and there are also several minor issues (some sizing problems with iframes, as pointed out by Charles; stylesheet propagation into sandboxes; strict symmetry of restrictions on iframes). We can't do something like this: body pHello, you said: sandboxHello World/sandbox /p /body ...because nothing stops the user from inserting /sandbox into the string -- e.g. if the user tried to insert /sandboxscriptalert(window.cookie)/script the result would be: All attempts to treat user-submitted HTML as a string are doomed to having such vulnerabilities. sandbox alone doesn't add much to this problem. Just look at how complex is the HTML sanitizer in LiveJournal which allows some user-submitted markup but not all. The only ultimate solution here is to parse the user-submitted HTML with an HTML5 parser and reserialize it. The string /sandboxscriptalert(window.cookie)/script would parse into one script element with a text node inside (stray /sandbox at the start gets ignored), and reserialize as scriptalert(window.cookie)/script. That's the only reasonable way (apart from completely escaping all characters) to include ANY user-submitted string into generated HTML, with or without sandbox. The sanest way I can see of limiting scripting is to give it its own browsing context (aka scripting context, or global scope). Anything short of this would make the security model overly complicated -- the security model is what we want to keep at its simplest, as I've said several times in this e-mail. sandbox would indeed be one, just with the content supplied inline. This basically implies an iframe, again possibly with the data in a data: URI, and combined with a way to ioslate the content in the iframe from the content of the parent browsing context: iframe src=data:text/html;base64,PHA%2BVGhpcyBpcyBteSBzYW1wbGUgbWFya3VwITwvcD4%3D isolate-scripts /iframe data: URIs are maybe appropriate for a small list-bullet PNG, but not for a blog entry or comment. They are ugly and impossible to read and write without machine conversion. Any element that lets you write the HTML content inside, be it iframe or sandbox or something else, would be OK. The names above are a bit long; here's a summary of what the four modes could be: seamless - if present, styles cascade through the browsing context boundary; ignored if the origin doesn't match the parent's. noscript - disables all scripts in the embedded page isolate - make the origin of the file not match the parent's, regardless of the real origins restrict - disable certain APIs in the browsing context These make a nice list of toggle attributes for the sandbox element. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] additional empty elements
On Tue, 01 May 2007 21:21:20 +0200, Brenton Strine [EMAIL PROTECTED] wrote: A nice solution would be the addition of a few div tags. (e.g. div2, div3, div4 and div5.) Then you could do something like this: HTML is a language for markup meaningful by itself, not just as a hook for CSS. div2 doesn't mean anything. I am okay with the unimaginative numbering of the extra elements, as it would make it easy to have a lot of new elements. However, there are countless possibilities: section, chunk, partition, block, enclosure, zone, figure, sector, quadrant etc... This is something that WHATWG is already doing (section, footer etc), basing on the popularity of certain classnames found in the wild. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] sarcasm
On Wed, 25 Apr 2007 01:35:15 +0200, Brenton Strine [EMAIL PROTECTED] wrote: So why not use the q element for irony as well, since a quote already indicates both quotations and irony. For the same reason why we don't want i used to mark up emphasis, foreign words and defined terms (since italics are already used in typography for all of this). -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] sarcasm
On Tue, 24 Apr 2007 22:18:23 +0200, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: It occurs to me that one of the most frequently used nits of pseudo-markup is to indicate sarcasm. For example, sarcasmYeah, George W. Bush has been such a great president./sarcasm Should we perhaps formalize this? Is there any benefit to be achieved by adding an explicit sarcasm element to HTML? In Western typography, there is already a tradition to mark up irony with quotation marks: Yeah, George W. Bush has been such a “great” president. I don't think a structural markup is required for something that has a punctuation tradition, just like we don't introduce structural markup for sentences (the punctuation, such as a full stop after the sentence, suffices). Also... I've heard that Ethiopian Semitic languages and French actually has a punctuation mark for sarcasm. There was such an idea, but it hasn't been widely adopted. http://en.wikipedia.org/wiki/Irony_mark -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Apply script.defer to internal scripts
On Thu, 29 Mar 2007 09:19:47 +0200, Kristof Zelechovski [EMAIL PROTECTED] wrote: The script embedded here is so short and specific that it makes no sense relaying it to an external location; however, if the script is not deferred, the script fails with an exception at run time because the document body is not constructed yet. What's wrong with simply placing it after /body? You do not place a script element after the body element: 3.6.1. The html element Content model: A head element followed by a body element. Sorry, immediately before /body. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Apply script.defer to internal scripts
On Thu, 29 Mar 2007 13:07:58 +0200, Gareth Hay [EMAIL PROTECTED] wrote: What about the DOMContentLoaded event? It is supported by Mozilla and, apparently, Opera 9. Dean Edwards has a technique to make it work on IE, and jQuery supports it on Safari [1]. Is there any chance DOMContentLoaded will be part of HTML5? imho, doing something like this is a much better solution, again imho. How is this better than putting the script immediately beefore /body, which already works today? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Apply script.defer to internal scripts
On Tue, 27 Mar 2007 21:49:41 +0200, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
Consider the following example:
script type=text/javascript defer
function ha8validate(p5event) { return true }
document.forms[0].onsubmit = ha8validate
/script
The script embedded here is so short and specific that it makes no sense
relaying it to an external location; however, if the script is not
deferred, the script fails with an exception at run time because the
document body is not constructed yet.
What's wrong with simply placing it after /body?
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Video proposals
On Mon, 26 Mar 2007 13:59:14 +0200, Benoit Piette [EMAIL PROTECTED] wrote: In the same train of thought, a document tag might be useful. I always found anoying that for many embeded documents (word or pdf) you would have a second user interface that have similar functionnality to the web browser (ex: search within a document). Something like document src= type=application/ms-word /. Having a consistent API and consistent user interface for an embeded document would be certainly useful. Imagine a consitent interface (user and API) for an embeded word document, a pdf, or even an editable content / controls for a CMS, wiki or a blog... Of course, creating an API that can edit both a PDF and a Word document is something daunting to say the least... But something that could be useful for simple content creation (like in a simple CMS, blog or wiki, something that can actualy generate valid HTML!) and general document embedding for viewing might be possible. There is iframe for this. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Markup for external content
On Fri, 23 Mar 2007 18:59:47 +0100, Henri Sivonen [EMAIL PROTECTED] wrote: * applet: the (old) way of activating Java. Probably must also die, though I'm unsure about this one. Why must it die? Browsers have to support it anyway, so documenting it and letting it pass conformance checking seems sensible. I don't like applets, either. In fact I've never seen a Java applet that wasn't either useless, better implemented in JavaScript, better implemented in Flash or better in a window of its own rather than in a replaced element rectangle. Still, pretending that applet doesn't exist won't make applets disappear. :-( It wasn't about applets that they must die. It was rather about this particular markup. And I'm not sure. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] source
On Fri, 23 Mar 2007 13:36:15 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: I don't really like this element. The name is confusing especially with an attribute named src=. It also introduces yet another void element, can't we just reuse param? The value= attribute of param would point to a resource and the type= attribute (which has been dropped) would be added back. I suppose it might be considered overloading, but in a way we're just defining how the processing model of a plugin could also work... If you put it inside object fallback content, it will be misunderstood by the current browsers as pertaining to the object. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] WF2: Non-validating submit buttons
On Wed, 21 Mar 2007 17:23:21 +0100, Christian Schmidt [EMAIL PROTECTED] wrote: It would be useful to be able to mark certain submit buttons as non-validating. input type=submit validate=no / How would this be achieved using script? One way is to use a button with the following onclick handler: One of the most appealing advantages of WF2 over HTML4 forms is the ability to express validation requirements declaratively without resort to scripting. If bypassing validation requires scripting, it defeats the advantage. An author could as easily write the validation code in JS rather than expressing validation constraints using WF2 but writing a script to get around validation. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Attribute proposal: video autostart
On Mon, 19 Mar 2007 08:17:16 +0100, Sander Tekelenburg [EMAIL PROTECTED] wrote: Therefore (to ease authoring and thus help adoption) I would like to propose a new boolean attribute for video: autoplay=autoplay. It's presence would be equivalent to invocing play() on the video ASAP. If it's a boolean, why not autoplay=true? Or if you want to make it easy for less-techy authors, just a valueless autoplay atribute. (At the very least, this sort of thing should be consistent throughout the spec. HTML 4 and CSS 2 are inconsistent in this area, which makes it too easy for authors to make mistakes.) Automatic behavior in HTML has been traditionally expressed through scripting. It's not hard to write a one-line script which automatically starts playback, but solutions based on scripting are easier to circumvent on the user side (and it's good). -1 for |autoplay|. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] require img dimensions to be correct?
On Sun, 18 Mar 2007 00:28:30 +0100, Andrew Fedoniouk [EMAIL PROTECTED] wrote: I think that in most cases will be better if we could package complex pages into zip envelopes and deliver them in the whole. That would be real solution of jumps. And img width=... height=... is a palliative. Such a technology exists: MHTML. However, it's a waste of traffic to include repeated images with every page served. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Video proposals
On Fri, 16 Mar 2007 17:57:01 +0100, Nicholas Shanks [EMAIL PROTECTED] wrote: All said, it would be very useful if the startpos param could be returned to the server when starting the download, or when scrubbing forward into parts of the video that haven't yet downloaded. as that would help avoid using bandwidth unnecessarily. I see two ways to do that over HTTP: 1) As a HTTP header 2) In the URL For a long time, HTTP provided support for this through non-default units in the Range header. Usually servers only support bytes as the measurement units, but the HTTP spec actually allows to use seconds, pages, chapters and so on, and defines a clear way for the server to indicate the support for this. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
[whatwg] Markup for external content
, though I'm unsure about this one. * iframe: subdocument. Though object can do the same, iframe is specifically designed for structured content and provides a DOM API for access to the contained DOM. Also more semantically precise. * Foregin namespaces in XHTML (svg xmlns=http://www.w3.org/2000/svg; and such): subdocument. This method allows access to the contained DOM but doesn't expose any image-, audio-, or video-specific API. Probably it should. About plugins: in early browser development, it used to be the case that every new browser feature got itself a new element. That's how come we now have object, embed, and applet. So, embed was the way to mark up certain types of external content just because the first browser to implement it did so with a plugin. I believe such implementation details should not affect the design of HTML anymore. There shouldn't be any specific markup for plugin content because we never know whether support for a particular format is going to be implemented with a plugin. There are plugins which add PNG support to old browsers. On the other hand, it's possible to implement Flash support natively using an open-source player library. Especially on a mobile device it's unlikely that the browser is going to have any plugin system. That's why I strongly disagree with the idea of having video only support open formats and leaving proprietary formats to object. Any video format which the browser can play, no matter natively or through a plugin, should be supported with video, as long as it's technically possible to expose a woring video DOM API to control the underlying implementation. Even Flash supports the notion of pausing and seeking to some extent, and is therefore a candidate for video. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
[whatwg] Video playback UI
Recently, there has been some debate about whether the browser should
present its own standard UI for playback control or let the authors design
their own UI (branded and consistent with the site design).
Browser-provided UI has the advantage of having the same UI across all
pages, which the user can get familiar with, as well as making it easier
to just put a video clip into a blog entry. Also, when the authors have
to implement their own controls, they can easily neglect some of the less
important ones (like seek contols), resulting in poorer usability and
accessibility.
Author-provided UI has the advantage of allowing branded design. Without
this, there might be not enough incentive for authors to switch to video
because Flash makes it possible to do branding.
A compromise solution that I propose is to include a standard set of
browser-provided controls, displayed by default and styleable through CSS
pseudo-elements and pseudo-classes:
video
:playing (pseudo-class)
:stopped (pseudo-class)
:toolbar (pseudo-element)
:button (pseudo-class)
:play (pseudo-element)
:pause (pseudo-element)
:stop (pseudo-element)
:rew (pseudo-element)
:ff (pseudo-element)
...
Examples:
Hide the controls completely:
video:toolbar { display: none }
Provide a border for all buttons:
video:toolbar:button { border: thin black }
Provide a custom icon for the Stop button:
video:toolbar:stop { background: url(...) }
By default, pause button is only shown while playing and hidden while
stopped. Override this:
video:stopped:pause { display: block }
Advantages:
* With default styling, video has a set of ready-to-use playback
controls.
* It's possible to express branded design or even completely get rid of
the controls.
* Styling can be overriden in the user agent (user CSS).
Disadvantages:
* Requires implementation effort in browsers.
* Makes it impossible to do such branding which cannot be circumvented.
Being a user myself, I'd rather consider it a feature.
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Video playback UI
On Sun, 18 Mar 2007 19:18:00 +0100, Anne van Kesteren [EMAIL PROTECTED]
wrote:
A compromise solution that I propose is to include a standard set of
browser-provided controls, displayed by default and styleable through
CSS pseudo-elements and pseudo-classes:
I think this is far too complex for such a simple feature. What's
outlined in the current draft, with a possible future extension of
video ui to turn UI on seems more sensible, easier to support and
easier to author.
I accept the point about implementation complexity, but I still think it
would be better if the UI was on by default and could be disabled by the
author. Otherwise, the author can just forget to enable the UI without
actual intention to implement his own, degrading usability of the page.
I don't think that one :toolbar pseudo-element which could be hidden as
follows adds too much to implementation complexity:
video:toolbar { display: none }
It's also important because CSS styling can be overriden by the user, whie
an attribute on video element generally cannot.
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] List of links idea (href= stuff)
On Wed, 14 Mar 2007 14:22:57 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: Maybe we can change the content model of ul (and perhaps ol) to allow a series of a elements: ul a href=test/a It would make styling harder (one would need to specify ula and ola rules in addition to li). This is probably only a minor drawback, but the gain from this enhancement is also long (saving from typing four characters li). -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Comments on the video element
On Sun, 18 Mar 2007 22:07:20 +0100, Mihai Sucan [EMAIL PROTECTED] wrote: 3. Personally, I believe the native UI should opt-out, not opt-in. video element implementations should not be required to implement native UI, however, if authors want to have their own custom UI, then they must set video ui=none (or something similar). I believe the implementations should be required to implement native UI. Otherwise the author who writes video src=... couldn't be sure that the UI will be there, and he would have to implement a custom UI anyway. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On Sat, 10 Mar 2007 11:16:09 +0100, Mihai Sucan [EMAIL PROTECTED] wrote: Alexey, actually I'm skeptical about this. First impression I had reading the first post was hey, do we need yet another switch?. What's super-duper standards mode after all? How will tutorials look: 1. For quirks mode use no DOCTYPE. 2. For standards mode use one of the following DOCTYPEs: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0//EN http://www.w3.org/TR/REC-html40/strict.dtd; 3. For super-duper standards mode use the following DOCTYPE: !DOCTYPE html The tutorials will just say Use !DOCTYPE html. My point is: we either want it, or not, what we have today called as standards mode is also buggy (each browser has its own set of rendering bugs). If IE adds the third level of rendering, then we have yet another DOCTYPE switch. Microsoft needs to make the improvements in the current standards mode - as they did now with IE 7. They need to continue this. The reason why modes other than the best standards mode exist is that a significant number of existing documents are written while keeping the non-standard browser behavior in mind, and it's unacceptable to change the rendering of those documents dramatically. Actually, the best standards mode available is the only right mode to work in. The other modes are only supported for backward compatibility with existing documents. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Thu, 08 Mar 2007 05:04:20 +0100, Michael Day [EMAIL PROTECTED] wrote: One downside of using HTML is that errors in the document can cause odd behaviour and can be harder to track down than errors in XML/XHTML. Using an HTML4 validator or HTML5 conformance checker to ensure that the document won't trigger error recovery is always a good idea. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 16:14:40 +0100, Julian Reschke [EMAIL PROTECTED] wrote: Interesting, but not of much use. If an author really wants to support MSIE, she needs to not only ensure that MSIE tries to render the document at all by setting its MIME type to text/html, but also to not use anything XHTML-specific that isn't possible in HTML, e.g. p inside li, or inline SVG. And if one isn't going to use these features anyway, there is no reason to prefer XHTML over HTML other than following the fashion. Why would a P inside LI be illegal in HTML? My fault. Should actually read: ul inside p. http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%3Cem%3E%3Cp%3EX -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 17:20:29 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: Personally I'd just give everyone HTML unless they specifically ask for XML and even then those tools should be capable of handling HTML imo. After all, it's the exchange format of the web. HTML is the exchange format only when there's a human in the loop. HTML is really only suited for exchanging certain basic kinds of narrative documents for eventual display to people, who will do the heavy labor of interpreting them. However, there's a lot more than that on the Web, and those use cases aren't really served by HTML at all, not even XHTML. I agree that XHTML really covers more use cases than HTML because XHTML is a richer language (can represent a wider set of DOM trees). But because your article is about serving XHTML in an MSIE-compatible way, the requirement of compatibility with MSIE effectively bars the author from fulfilling those extra use cases. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 19:14:25 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: Neither is really my point. The problem with malformed HTML is that it has an inconsistent DOM. You get different DOMs in different browsers and tools. Making a document well-formed XHTML gives you a consistent, reproducible, predictable DOM. Making a document conformant HTML gives you a consistent, reproducible, predictable DOM. Even more: a non-conformant document, when parsed with a HTML5 parser, also gives a predictable DOM. With HTML 5 parsers (which we don't have yet) the DOM of malformed documents may yet become predictable, but it won't ever be obvious. And it may well not be consistent across browsers unless Microsoft jumps on board. By contrast, valid strict XHTML (probably transitional too) has a reasonably consistent tree structure in all browsers today. The DOM of valid HTML documents is predictable and consistent across browsers today. Once you achieve well-formedness you can begin looking at the document in a new way. You get access to powerful tools like XPath and XSLT that you didn't have before. You can start doing more than merely tossing the page at a browser for rendering. And you don't have to wait for an HTML 5 parser to do it either. You can do it today with a large tool chain. You can use XPath and XSLT on a DOM tree obtained by parsing HTML, can't you? If your HTML is valid, you don't even have to wait for an HTML5 parser -- a variety of HTML4 parsers is available today. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 20:04:08 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: Yes, and I use it. However it constantly surprises people in the markup it generates, as hanging out for a day or two on the tagsoup-friends mailing list will show. That's not it's fault. There's just no one obvious way to fix all the broken markup that's out there. TagSoup picks one approach. HTML 5 picks another. Both will surprise people a lot of the time. At the parser level that can't be helped. However at the document level it can be helped. When the document author takes the care to generate a well-formed document, they are rarely surprised by the resulting tree the parser builds. The tree is explicit in the markup. Explicit markup is more obvious and less surprising than the implicit fill-in both TagSoup and HTML 5 do. There's nothing surprising in the DOM that TagSoup generates when parsing a valid HTML4 document. Hmm, that brings up another question. Does the HTML 5 fixup algorithm ever change the *tree* for a well-formed (but invalid) document? There is no notion of well-formedness for HTML. A document is simply either conformant to HTML5 or not. For instance, if it finds an li element that is a child of a p, what would it do? Either ignoring the li/li tags, skipping the li element completely, or filling in a ul element would all change the tree. That would be a non-conformant document. According to HTML5, such document will be parsed into a tree which, when serialized, would result in text different from the text of the original (non-conformant) document. I suspect it does one of these three things (or something similar like filling in an ol element) but without opening the spec or writing a sample program, I can't tell you which. By contrast with a real XML parser, I can tell you what's going to happen without cracking open the spec. HTML5, TagSoup, and XML parse trees are all deterministic and thus predictable; but only the XML tree is *obvious*. HTML5 unambiguously defines what should happen. To summarize: 1. Parsers in today's browsers generate predictable DOM for valid HTML4 documents. 2. A conformant HTML5 parser generates predictable DOM for both conformant and non-conformant HTML5 documents. Also, the result of parsing a valid HTML4 document with a today's browser, as well as the result of parsing a conformant HTML5 document with a conformant HTML5 parser, are both predictable and obvious (i.e. it doesn't require actually performing the complex HTML5 parsing alorithm in your mind to predict the resulting DOM). So, if you stick to valid HTML4 (or, in the future, conformant HTML5), you'll get both predictable and obvious results. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 22:11:15 +0100, Kornel Lesinski [EMAIL PROTECTED] wrote: User-agent sniffing is a bad practice - it's inaccurate, hurts minority browsers and is not forward-compatible. Please change your method to use Accept header, so it won't be affecting any HTML-only user-agents (web is more than a handful of desktop browsers). Accept method will even work for MSIE and Lynx when/if they start supporting XHTML. Even your regular expressions for User-Agent aren't doing exactly what you intended, because mod_rewrite does not anchor patterns. While I totally agree that browser sniffing isn't a way to go, I must say that Accept headers cannot be used to resolve this because MSIE claims to support */* in the Accept header that it sends. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On Wed, 07 Mar 2007 21:47:34 +0100, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: I'm not sure if it has been discussed earlier, but after seeing Chris Wilson's talk on «Browser Wars Episode II: Attack of the DOMs»[1] I think it's pretty obvious that Internet Explorer needs a new switch of some sort, to be allowed to implement and fix the DOM, JavaScript, CSS1-3 etc. without breaking backward compatibility. At least that's what Chris Wilson says. And I agree. Internet Explorer needs a new switch. So I thought, what about using: !DOCTYPE html as the new switch? This is a plain simple yet brilliant idea. Other browsers can also use !DOCTYPE html as an indication to stop applying certain hacks which make them diverge from standards in favor of interoperability with IE. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] href attribute
On Fri, 02 Mar 2007 17:55:34 +0100, Colin Lieberman [EMAIL PROTECTED] wrote: One of the strengths of the current XHTML2 spec is the broadened use of the href attribute (http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html#adef_hyperAttributes_href) -- and the resulting requirement for user agents that any element with a (valid) href element be an actionable link. Any element can be made into a button, but HTML has the button element to explicitly express the button semantics. I think you won't argue that button onclick=...Calculate/button ...is preferable than span class=button onclick=...Calculate/span Likewise, HTML has a to explicitly express the semantics of a hyperlink. I don't see how the language would benefit from the ability of turning any element into a link. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Input field's hint value
On Wed, 21 Feb 2007 11:28:47 +0100, Wolfram Kriesing [EMAIL PROTECTED] wrote: I was searching, but didnt find a hint-attribute for an input. The more often we are using inline editing, the more the need for the following is rising, imho: input type=whatever hint=Enter your title here / The text Enter your title here is shown as the value while no value is given, or when the field is empty, upon focusing the element this string disappears. If no value was entered this text is shown again ... I guess its clear what I think of here, a lot of apps already have that. I could also imagine styling this hint text differently, may be customizable. Is there already such a thing? From the semantic standpoint, I believe this is what the title attribute expresses. Please somebody correct me if I'm wrong, but this behavior (show the value of the title attribute whenever the control is not focused and has empty value) can already be specified with CSS over WF2. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Definition list and tables: what's the difference ?
On Wed, 14 Feb 2007 01:50:29 +0100, Simon Pieters [EMAIL PROTECTED] wrote: OK, in this example you're abusing rows, not columns. Rowspan and colspan allow you to make one cell be part of several rows or columns, which means that (by usnig only one dimention, and without using headers=) a data cell can be associated with multiple header cells, or if it is a header cell, multiple cells can be associated with it. It's what they were designed to do. But you can't make *each* of A, B, and C associated with *each* of X, Y -- that's what the example below does. What about this? dl dtA/dtdtB/dtdtC/dt ddX/Y/dd /dl -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Definition list and tables: what's the difference ?
On Tue, 13 Feb 2007 00:24:33 +0100, David Latapie [EMAIL PROTECTED] wrote: The title may seem silly: tables are completely different from definition lists; the only similarity is that they are both block elements. Well, on the presentational level, I could not agree more. But when you come to think to the semantics, I am not so sure. What follows is pure speculation from me -- not a request for any change, just some thoughts I would like your opinion on. Because I truly wonder if dl and table are different enough. Maybe this is just theoretical (practicability/compatibility may render the whole idea useless), but I would still like your opinion, especially considering the amount of talented people on this list. The fundamental difference between tables and definition lists is that a table is a two-dimensional mapping of a pair of axes to one value, and a definition list is a uni-dimensional mapping of a term to one or more definitions. While there are some cases when either a table or a definition list can be used at author's choice, generally their use cases are different. The most notable case when a table is inappropriate to replace a definition list is when a definition list contains multiple definitions for each term or group of terms. While multiple definitions can be either stuffed into one table cell or laid out in a row, both solutions seem like a workaround. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Definition list and tables: what's the difference ?
On Tue, 13 Feb 2007 15:40:13 +0100, David Latapie [EMAIL PROTECTED] wrote: My humble point: table can do everything dl can, whilst the reverse is not true. He who can do more can do less. table canot do this: dl dtcomputer/dt ddAn electronic device for information processing./dd dtdriver/dt ddA computer program taking care of direct communication with a peripherial device./dd ddA person who drives a vehicle./dd /dl How would you represent this in a table without abusing the very idea of columns? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Definition list and tables: what's the difference ?
On Tue, 13 Feb 2007 16:17:57 +0100, Simon Pieters [EMAIL PROTECTED] wrote: How would you represent this in a table without abusing the very idea of columns? Don't know what you mean with abusing columns, but: OK, in this example you're abusing rows, not columns. table trthcomputertdAn electronic device for information processing. trth rowspan=2drivertdA computer program taking care of direct communication with a peripherial trtdA person who drives a vehicle. /table What about this? dl dtA/dtdtB/dtdtC/dt ddX/Y/dd /dl -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] live image maps
On Sat, 10 Feb 2007 12:29:46 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: I think the specification should be clearer about what happens when an area element is added or removed. When an img element is added with a usemap=. When the shape= attribute is altered, et cetera. Either by handling each case specifically or stating in general that the specified algorithms always apply or something. Isn't it implied that any modification to the DOM tree should be equivalent to replacing the document with another one which would parse into the resulting DOM? If not, maybe it's worth specifying that this holds true unless explicitly stated otherwise. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] require map id
On Sat, 10 Feb 2007 10:29:08 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: Without an ID attribute a map element is useless. Perhaps in addition a useful requirement would be that this ID attribute is referenced from an image (either img usemap or object usemap). Such images can be added later by a script. But I agree about requiring the id. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The m element
On Thu, 08 Feb 2007 07:46:09 +0100, Charles McCathieNevile [EMAIL
PROTECTED]wrote:
If I want to note a word in something someone else said ('does emphasis
*change*
the meaning, emphasis mine' is what you find in current usage) which tag do I
use?
IMO this is exactly the use case for m.
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The m element
On Thu, 08 Feb 2007 16:23:33 +0100, Leons Petrazickis [EMAIL PROTECTED] wrote: In the Western world, the standard for highlighting is a neon yellow background. I submit that a much better name for m is hi (hilite, highlite, highlight). People don't necessarily mark text much -- if anything, mark implies underlining, circling, and drawing arrows -- but they do highlight. In university, I often saw students perched with their notes and a highlighter, marking important sections. The semantic meaning is to draw attention for later review. The default styling of hi would be a neon yellow background. Google's choice of #66 could well be suitable. A very good idea. I support it. On Thu, 08 Feb 2007 16:51:23 +0100, James Graham [EMAIL PROTECTED] wrote: Sure. But what useful features could a general purpose UA implement if this semantic information is made avaliable to it? 1. Offer navigation (next/previous) amonng highlighted regions in the document. (Probably only amongh hi sharing the same class.) 2. Turn highligting on/off. Google currently implements it thorough page reload (serves a version without highligting), but this could be done client-side. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] WF2: Non-validating submit buttons
On Wed, 24 Jan 2007 19:03:58 +0100, Martin Atkins [EMAIL PROTECTED] wrote: It would be useful to be able to mark certain submit buttons as non-validating. Use case: lots of the forms generated by one of my web-apps have a Cancel button which simply causes the server to redirect the user back to wherever they came from. When I use the WF2 extensions to mark required fields, formats, etc the Cancel button won't submit until the form is completed correctly. This doesn't make much sense from a UI perspective. I second that. Antoher use case is saving an unfinished form on the server so that the user can continue filling it later. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] WF2: Non-validating submit buttons
On Wed, 24 Jan 2007 20:20:50 +0100, Thomas Broyer [EMAIL PROTECTED] wrote: It would be useful to be able to mark certain submit buttons as non-validating. Use case: lots of the forms generated by one of my web-apps have a Cancel button which simply causes the server to redirect the user back to wherever they came from. When I use the WF2 extensions to mark required fields, formats, etc the Cancel button won't submit until the form is completed correctly. This doesn't make much sense from a UI perspective. Cannot you accomplish that by using two forms? Actually, the Cancel button could easily be just a link, not a submit control. However, this doesn't solve the use case of saving an unfinished form server-side. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] contenteditable, em and strong
On Fri, 12 Jan 2007 09:41:42 +0100, Henri Sivonen [EMAIL PROTECTED] wrote: Is the effort to get people to use CSS instead of table for layout a bad idea? It often is, sadly. When people really, really want a grid layout model and try to fake it with positioning or floats, the result tends to be more brittle and (particularly with positioning) less fluidly scalable than a table layout (positioning being worse than floats but see http://dbaron.org/log/2005-12#e20051228a ). Just a side note: for grid layouts, display: table-* should be used. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] font and style=''
On Fri, 12 Jan 2007 10:03:34 +0100, Henri Sivonen [EMAIL PROTECTED] wrote: Furthermore, I suggest allowing style='' on all elements, because only allowing it on div and span would only move WYSIWYG output even more to the direction of Karl Dubost's caricature of HTML 6.0. I second that. Excluding |style| would lead to hundreds of CSS rules with id-selectors to emulate that. I can't say it's better. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Hyphenation
On Tue, 09 Jan 2007 14:03:04 +0100, Leons Petrazickis [EMAIL PROTECTED] wrote: I would suggest that the first priority is getting a naive hyphenator into browsers. Since you only ever need hyphenation when full-justifying, I would suggest: align: hyphenated; In some typographical traditions, non-full-justified text is sometimes hyphenated. I believe that hyphenation should be a separate property, orthogonal to text-align. Also, there are some common hyphenation options (like the maximum number of consequtive hyphenated lines allowed) that are also worth CSS properties. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] contenteditable, em and strong
On Wed, 10 Jan 2007 01:20:50 +0100, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: Instead of doing that, people just swapped proper in place of capitalize. The adherents raged. What fools these people be. The first word of a sentence is not a proper noun. We need to proselytize more! I don't however your fable persuasive, because it presents the acceptance of markup as a dialectic between elite proselytization and authorial pragmatism, whereas I would allot greater explanatory power to the conservatism of tools and a certain disinterest on the part of tool developers in the meaning of text content. What happened to b and i -- because of the tools -- isn't random. Every presentational markup that today's web contains has this very reason: WYSIWYG. This approach is by design targetted at producing a document for presentation on one single, chosen media (which is usually either screen or paper). WYSIWYG is always presentational because its goal is to produce a document which is as close as possible to the “original” that exists in the author's imagination. If the author has imagined boldface text, it means that he has already performed the irreversible mapping from semantics to presentation in his head, and there is no way to precisely map it back to semantics. And it never was a goal for WYSIWYG; the task of every WYSIWYG tool was to give the user the right buttons to press for bold, italic, and underlined. There are indeed different reasons why the author may want an italic font, but making a separate button for each of those reasons won't do any good because the interface between the author and the tool takes place after the conversion from semantics to presentation, and a choice of “semantic” buttons wouldn't make any sense at that point. What would happen is that authors would pick a random button out of those which produce italic rendering, and consider the tool's interface overcomplicated. b and i are not alone here. Continuing the capitalization example, I can say that text editors have used to provide capitalization when the user holds the Shift key (pretty much like Ctrl-B for bold). Having several kinds of Shift keys for different purposes of capitalization (Start-of-sentence key, Proper-noun key, Acronym key) would not, in my opinion, help preserve more semantic information: the authors would pick the key to use randomly because it doesn't make any difference on the media this particular WYSIWYG tool targets. The only radical way to make semantic markup work is to abandon WYSIWYG and start thinking in a media-independent way (or, to reuse the word, multimedia). I'm not sure if it's feasible on the scale of the entire web authoring community, and what model should replace WYSIWYG in that case. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Dual mode for client?
On Wed, 27 Dec 2006 01:28:59 +0600, Mike Schinkel [EMAIL PROTECTED] wrote: I'm wondering if you collectively would consider adding the following to the spec; a recommendation that clients offer two modes; one mode being for users where the spec works as currently envisioned. The second mode would be for web developers and would generate errors for invalid markup as opposed to generating no errors (Ian had said it was preferred to not generate errors for invalid markup to ensure users were willing to use browsers based on the newer spec; a dual mode would give the best of both worlds.) The spec defines exactly under what circumstances are parse errors generated. I think it's out of scope to define how/whether these parse errors are reported. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] several messages about XML syntax and HTML5
On Mon, 18 Dec 2006 16:57:08 +0600, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: Humans don't work that way. If the words HTML (WARNING) or XHTML (WARNING) started appearing next to over 90 percent of search results, people would not think that something was wrong with 90 percent of Web pages. They would think that something was wrong with the search engine. I see no reason why that should be the case; and short of actual user tests with well-designed warnings I don't suppose we'll ever be sure. I would however definitely suggest better messages, since WARNING verges on being meaningless. Perhaps HTML (corrupted) and XHTML (corrupted) for documents that cite (or imply) a standard document type but clearly fail to conform to it, text/html (non-standard variant) for text/html documents that do not cite (or imply) a standard document type, and XHTML (broken) for non-well-formed XHTML. Maybe the other way round? Valid [X]HTML on valid documents? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?
On Fri, 15 Dec 2006 15:49:24 +0600, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: I think basic conformance is part and parcel of creating an accessible, interoperable site; but it's worth noting that there are plenty of captains of accessibility who reject that viewpoint, e.g.: http://www.anysurfer.be/ They do mention validation: http://www.anysurfer.be/fr/obtenir-label/procedures-de-labellisation/la-validation/ -- though I'm not sure they mean ensuring valid HTML. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] reset element?
On Fri, 15 Dec 2006 23:45:52 +0600, Dean Edwards [EMAIL PROTECTED] wrote: But this element would be purely for the purpose of interacting with CSS so it does indeed seem to be a CSS issue. Not entirely. It also has some semantic value in that the element acts as a container for other elements that comprise a widget. Perhaps reset is the wrong name. I can't think of anything better though. Like I said, I don't like the name widget but it gives a better idea of what the element is. Elements comprising a widget should carry appropriate semantic value by themselves. For example, a properly styled unordered list can be used as a color picker. widget should not be used as an excuse for writing a bunch of meaningless divs to make a custom control. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] reset element?
On Fri, 15 Dec 2006 23:56:42 +0600, Dean Edwards [EMAIL PROTECTED] wrote: Elements comprising a widget should carry appropriate semantic value by themselves. For example, a properly styled unordered list can be used as a color picker. widget should not be used as an excuse for writing a bunch of meaningless divs to make a custom control. Agreed. But if I add input boxes for Red, Green and Blue and some OK/Cancel buttons and wrap those up in a widget element then I feel like I've added semantic value not reduced it. In this context, fieldset would express the meaning better. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?
On Fri, 15 Dec 2006 13:01:01 +0600, Matthew Paul Thomas [EMAIL PROTECTED] wrote: Personally, I would *love* Google to do this sort of thing. I just have no hope for it. http://labs.google.com/accessible/ Interesting. But this lacks one important thing: a clear indication of why some page doesn't qualify as accessible. Google seems reluctant to disclose their criteria, and it's a pity. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] several messages about XML syntax and HTML5
On Tue, 12 Dec 2006 02:53:50 +0600, Ian Hickson [EMAIL PROTECTED] wrote: They will, and old browsers will show either fallback content, if provided, or nothing at all in place of the new-feature. I don't see how is this rendering better than showing an error message for malformed new-feature content. Based on my experience, nothing at all is better than an error message in so far as what users think. Nothing at all, they ignore. An error message, they say why is the browser broken? My old browser wasn't broken. I'm going back to my old browser. Case 1. The embedding is invalid. Old browser: Here is the sketch I drew yesterday: (and no sketch). New browser: Here is the sketch I drew yesterday: ERROR. In this case, the page is equally broken in both browsers. The new browser is even more informative because it at least explains that there should have been an image, and probably the reasons why it can't be displayed. Case 2. The embedding is valid. Old browser: Here is the sketch I drew yesterday: (and no sketch). New browser: Here is the sketch I drew yesterday: ACTUAL SKETCH. In this case, the rendering of the new browser is undoubtedly better. To summarize: in either case, the rendering of the new browser is *not worse* than that of the old browser. You won't be able to manipulate the SVG DOM in this case. Your use case didn't mention manipulating the DOM. Moving targets are hard to hit -- that's why we try to list the use cases before designing the solution. The use case wasn't mine. :-) These are actually two independent aspects: 1. Native support vs. plugins. 2. External resources vs. inline data. Native support + external resources -- e.g. JPEG img href=http://...; Plugins + external resources -- e.g. Flash Native support + inline data -- e.g. JPEG img href=data:... Plugins + inline data -- no examples yet, but why not? Why not is not a design process, sorry. The why not is for implementations, not for the spec. Using native support or a plugin is completely up to the implementation. There can even be a third way: for example, add-on support for embedded MathML is avaliable as a UserJS for Opera -- this works somewhat like a plugin but is written in JS. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] several messages about XML syntax and HTML5
On Mon, 11 Dec 2006 05:27:14 +0600, Ian Hickson [EMAIL PROTECTED] wrote: ...in new browsers, then it looks worse in new browsers than old ones. Thus, new browsers will want to go back to the way that old browsers handled it, so that they don't handle it worse than the (old) competition. I disagree with you here. [...] if the new-feature is completely new, such as the proposed xmldata, then the only documents containing new-feature would be those that target the new browsers which support it. You assume that documents targetted at new browsers will not be seen in old browsers. This isn't the case (if it was, we wouldn't have people trying to send XHTML to HTML UAs). No, I don't. They will, and old browsers will show either fallback content, if provided, or nothing at all in place of the new-feature. I don't see how is this rendering better than showing an error message for malformed new-feature content. You also assume that documents that contain the new feature will not be targetted at older UAs. This is also not the case (if it was, we wouldn't have things like noscript, noframes, etc). Maybe they will. If so, they will provide fallback content. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] several messages about XML syntax and HTML5
On Mon, 11 Dec 2006 06:25:27 +0600, Ian Hickson [EMAIL PROTECTED] wrote: 1.) Inserting Sam Ruby's SVG logo into HTML, for one example. The img element already supports images in HTML. You can even embed images directly in the page with data: URIs, regardless of the format (be it PNG, JPEG, or SVG, for example.) You won't be able to manipulate the SVG DOM in this case. Also, data: URIs are inconvenient to write, and they are only usable for very short data strings. We already have such a mechanism, namely, plugins. Two extension mechanisms are not possible? Redundancy is always possible. Whether it is desireable is the question. These are actually two independent aspects: 1. Native support vs. plugins. 2. External resources vs. inline data. Native support + external resources -- e.g. JPEG img href=http://...; Plugins + external resources -- e.g. Flash Native support + inline data -- e.g. JPEG img href=data:... Plugins + inline data -- no examples yet, but why not? External resources vs. inline data are the ways that the spec defines things (e.g. data: URIs). Native support vs. plugins is what implementors decide, and it may vary from implementation to implementation (e.g. one browser displays PNG natively, another one does it through a plugin); this choice shouldn't affect how documents are written. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Common Subset
On Sat, 09 Dec 2006 03:15:45 +0600, Michel Fortin [EMAIL PROTECTED] wrote: Another noteworthy problem with the common subset about scripting is that it's really impractical to write some idioms. You can't have any instance of or in a script without throwing the document outside of the common subset: HTML requires them to be unencoded, XHTML requires them to be in a CDATA section or escaped as lt; and amp;. The CDATA solution would probably work in HTML, although it'd make the document non-conforming. The HTML5 spec could somehow officially bless CDATA only when used like this: script//![CDATA[ ... //]]/script It would not harm because it is already interoperable. But it seems somehow stupid to define that ![CDATA[ and ]] are only allowed inside script after //. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] @autosubmit on select
On Sat, 09 Dec 2006 06:54:12 +0600, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: Seeing how the select element is mostly used in the wild, I think an 'autosubmit' attribute on the select element will increase accessibility because the current deployed solutions all depend on JavaScript, usually without any kind of fallback to an ordinary submit button. Isn't menu more appropriate for the problem that auto-submitting select tries to solve? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] PaceEntryMediatype
On Sat, 09 Dec 2006 04:01:14 +0600, Ian Hickson [EMAIL PROTECTED] wrote: Why is it useful for a browser to make a list of a bunch of random feeds that have no relation to one another or to the current page? Well they sort of have a relation -- they're feeds that the author thinks the user would find useful. This is no more tight a relation than a page that the author thinks the user would find useful, which is usually expressed with a rather than link. This is something that happens already in the real world -- I'm just trying to make the spec distinguish alternate from feed when it comes to such feeds. Whoever is doing it abuses link. rel=feed means the feed for the current document, rel=alternate means an alternate representation of the current document. Therefore, rel=alternate feed means alternate representation of the current document by a feed. Currently the orange RSS icon means Subscribe to this page. This is a lot more useful (in my opinion) than it meaning subscribe to some random thing. No, it doesn't. It means subscribe to something the author made available. Currently you have no way to know if it is the current page's feed or just a list of random related feeds. Surely the author could have referenced any irrelevant feed but that's not a good thing to do. Conscious authors should only use rel=feed as defined in the spec. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] several messages about XML syntax and HTML5
On Thu, 07 Dec 2006 11:44:05 +0600, Ian Hickson [EMAIL PROTECTED] wrote: Here's an example. If this: ...text... new-featureerroneous content/new-feature ...text... ...displays like this: ...text... ...text... ...in existing browsers, but like this: ...text... ERROR ...text... ...in new browsers, then it looks worse in new browsers than old ones. Thus, new browsers will want to go back to the way that old browsers handled it, so that they don't handle it worse than the (old) competition. I disagree with you here. The above is only true if new-feature is actually an existing element which has been given new meaning, i.e. there are legacy documents on the web containing new-feature but using it in some other (old) meaning, or without a meaning at all (example: xmlns attribute in text/html). That way, browsers introducing new feature will have to back out because they would break existing documents. There was an example of this when Gecko tried to interpret xmlns in text/html. However, if the new-feature is completely new, such as the proposed xmldata, then the only documents containing new-feature would be those that target the new browsers which support it. These documents would use new-feature in the proper sense, and they would only contain errors due to reak mistakes made by human authors, not because of introduced incompatibilities. For these documents, ...text... ERROR ...text... is actually a better rendering than ...text... ...text... because it helps to locate and fix the error. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Common Subset
On Sat, 09 Dec 2006 18:50:58 +0600, Lachlan Hunt [EMAIL PROTECTED] wrote: The HTML5 spec could somehow officially bless CDATA only when used like this: script//![CDATA[ ... //]]/script It would not harm because it is already interoperable. It's technically already allowed because script and style elements are defined to contain CDATA. So basically any string of text that doesn't include '/' before the end tag is valid. Oops. My bad. Okay then, it's good that we have a way to write scripts in the common subset of HTML5 and XHTML5 without escaping every and . Only Opera (AFAIK) even implemented support for CDATA sections in HTML. So although that may suggest that they can be supported by browsers without breaking anything, their use wouldn't be backwards compatible with other legacy browsers, so they have to be forbidden. I'm not saying they should be allowed outside of script and style. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Inline SVG
On Sat, 09 Dec 2006 19:54:29 +0600, Michel Fortin
[EMAIL PROTECTED] wrote:
You'd need a JavaScript fallback in addition to noscript, something like
this:
script type=text/xml id=a
xml-element/
/script
noscript id=b
fallback content
/noscript
script type=text/javascript
if (/* browser does not support XML scripts */) {
if (/* has some javascript XML parser library */) {
parserLibrary.parseAndInsertXML(getElementById(a).textContent);
} else {
document.write(getElementById(b).textContent);
}
}
/script
It could also be an external script that justs search the document for a
particular class of noscript element once the document is loaded.
I'm afraid that noscript doesn't end up in DOM when scripting is enabled.
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Psuedo classes based on DOM Events
On Tue, 05 Dec 2006 13:18:00 +0600, Rohan Prabhu [EMAIL PROTECTED] wrote: i was just wondering, that in the Web Controls 1.0 specifications, in the psuedo classes specifications, could it be that the psuedo classes could also be the DOM Events which would modify the style information attached to it. Like for ex: #objectid:onmouseup #objectid:onmousedown #objectid:onmouseover #objectid:onmouseout #objectid:onkeypress Pseudo classes are representation of states (focused, disabled etc), not events (mousedown, keypress). -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] PaceEntryMediatype
On Wed, 06 Dec 2006 22:42:06 +0600, Ian Hickson [EMAIL PROTECTED] wrote: I mean that the feed might contain items that were never part of the page linking to the feed. For example, this page: !DOCTYPE HTML titleFeeds for this site/title link rel=feed href=status.xml link rel=feed href=news.xml link rel=feed href=links.xml pThis page links to the three feeds for this site. There are no items on that page, but it links to three feeds that the site provides. In your example, what's the relation between status.xml and this page? status.xml is just a resource that provides a syndication feed. It is not necessarily associated with a particular Web page. If there is no particular relation, then it should not be link. The link element is for resources which are in specific typical relations to the current document. I would mark it up like this: h1Feeds for this site/h1 ul lia href=status.xml type=application/atom+xmlStatus feed/a/li lia href=news.xml type=application/atom+xmlNews feed/a/li lia href=links.xml type=application/atom+xmlLinks feed/a/li /ul Note the absence of rel attribute on the a: there is no specific typical relation between the current document and the referenced resources. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
[whatwg] Inline SVG
On Mon, 04 Dec 2006 13:55:32 +0600, Ian Hickson [EMAIL PROTECTED] wrote: http://intertwingly.net/stories/2006/12/02/whatwg.logo Currently, there wouldn't be one. We could extend HTML5 to have some sort of way of doing this, in the future. (It isn't clear to me that we'd want to allow inline SVG, though. It's an external embedded resource, not a semantically-rich part of the document, IMHO.) People will do inline SVG anyway. If there won't be a straightforward way to do this, authors will use all kinds of dirty hacks, such as data: URIs and DOM manipulation. Personally, I don't think SVG content is inappropriate for HTML documents. It is no more presentational than the text itself: HTML doesn't try to structure natural language sentences by breaking them into grammar constructs, so an SVG image could be thought of as just an atomic phrase which only has defined semantics as whole. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] several messages about XML syntax and HTML5
On Mon, 04 Dec 2006 22:11:09 +0600, Michel Fortin [EMAIL PROTECTED] wrote: I was initially disappointed that !DOCTYPE html is well-formed because I though that it'd allow to differentiate HTML from XHTML documents unambiguously (since XHTML documents couldn't have it). That said, now I think it's probably irrelevant. The two format are not the same, but many people have been trying to find common ground since XHTML has been invented for various reasons. The result is a lot of HTML documents which are wrongly identified as XHTML (because they're not even well-formed XML). So I think dropping the HTML/XHTML identification string altogether is the right thing to do; it's meaningless anyway because a lot of authors are careless. Let's use the media type instead, the real thing browsers use to differentiate the two, and force people to make things well formed if they want it called XHTML by the validator. The DOCTYPE is only needed to trigger standards mode in browsers. That's why it has been stripped down so much that it's no more informative as a proper SGML DOCTYPE. The only features of HTML I see that are not supported by the subset are base vs. xml:base, and that you can't specify encoding within the file because one use ?xml encoding=? and the other use meta http-equiv=, but the encoding can still be set as a media type parameter). With application/xml, it cannot (and for good!). That doesn't leave much of HTML that can't be expressed by the subset. Am I missing something? Which useful features aren't part of the subset? noscript document.write() -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] several messages about XML syntax and HTML5
On Mon, 04 Dec 2006 20:43:15 +0600, Elliotte Harold [EMAIL PROTECTED] wrote: 1. Strong hand-authoring: static HTML written fully in a plain vanilla text editor with tags in view 2. Weak hand-authoring: templates hand-authored, content not My point then becomes, very little content on the web today is strongly hand authored, and the proportion continues to decrease. People who strongly hand author, or who create weakly hand-authored systems are competent to create well-formed markup if they choose to do so. People who merely use weakly hand authored systems do not see the markup, and do not need to be considered in our deliberations on this point. LiveJournal, a popular blogging service, inserts hand-authored content into hand-authored templates. While the templates are written by competent authors who (mostly) know how to write proper HTML, blog posts are most often written by people who barely learnt how to use a bunch of tags. LiveJournal makes some simple preprocessing (breaks paragraphs on newlines and strips dangerous markup like script) but otherwise leaves the content as is. That's why most blog pages on LiveJournal aren't even close to being valid HTML. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] several messages about XML syntax and HTML5
On Mon, 04 Dec 2006 17:10:08 +0600, Mihai Sucan [EMAIL PROTECTED] wrote: IMHO, requests for allowing the xmlns attribute and other XMLiness is a bit over the board. I am for allowing the trailing slashes, they do no harm, and they help us on the server side, under strict control. Also, according to statistics you've provided the trailing slashes are used right now on 50% of web pages. However, in the same spirit, a middle way for those who want XMLiness in HTML, would be to allow the xmlns:?.* attribute, xml:base, xml:id, and xml:lang. Yet, define them as meaningless. Just for validation purposes, just for helping people who do such things on the server-side. I don't think it's the right thing to do. Recently, br/ has been brought into the common subset of HTML5 and XHTML5. That's OK because browsers currently handle br/ the same in HTML and XHTML, and will continue doing so. The same for xmlns attribute on html. However, introducing xml:base into the common subset of HTML5 and XHTML5 is not acceptable becasue it there woudl be markup in the common subset that means different things for HTML5 and XHTML5 consumers: nothing for the former, base URI specification for the latter. I don't see why would anyone want non-interoperable markup in the common subset. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] PaceEntryMediatype
On Fri, 08 Dec 2006 04:31:25 +0600, Ian Hickson [EMAIL PROTECTED] wrote: !DOCTYPE HTML titleFeeds for this site/title link rel=feed href=status.xml link rel=feed href=news.xml link rel=feed href=links.xml pThis page links to the three feeds for this site. status.xml is just a resource that provides a syndication feed. It is not necessarily associated with a particular Web page. If there is no particular relation, then it should not be link. The link element is for resources which are in specific typical relations to the current document. This is not how link is defined in HTML5. 3.8.4: The link element allows authors to indicate explicit relationships between their document and other resources. What kind of explicit relationship do we have here? I would mark it up like this: h1Feeds for this site/h1 ul lia href=status.xml type=application/atom+xmlStatus feed/a/li lia href=news.xml type=application/atom+xmlNews feed/a/li lia href=links.xml type=application/atom+xmlLinks feed/a/li /ul Note the absence of rel attribute on the a: there is no specific typical relation between the current document and the referenced resources. Then the browser wouldn't take these links and make them available in a list of feeds interface, which is the problem we are trying to solve. Current browsers easily make lists of all links found on the page by enumerating all a elements. I can't see why a list of feeds cannot be a subset of that. The type attribute gives enough information for this, especially if combined with the proposed ;type=feed. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
[whatwg] The event-source element
I can't recall if it has been already discussed: Why do we need an event-source element in the markup? It only makes sense in conjunction with scripting, so I think it would be better to drop this element and have the event source objects only created by scripts. Similar practices are already established for objects like XMLHttpRequest, XSLTransform (to name a few). -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Start Tag Syntax
On Fri, 01 Dec 2006 13:39:27 +0600, Lachlan Hunt [EMAIL PROTECTED] wrote: 3. The start tag may have a number of attributes, the syntax for which is described below. Attribute names must be separated from the tag name or a preceding unquoted attribute value, and should be separated from a preceding quoted attribute value, by one or more space characters. Must be separated from a preceding valueless attribute as well. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Start Tag Syntax
On Wed, 06 Dec 2006 16:04:20 +0600, Anne van Kesteren [EMAIL PROTECTED] wrote: 3. The start tag may have a number of attributes, the syntax for which is described below. Attribute names must be separated from the tag name or a preceding unquoted attribute value, and should be separated from a preceding quoted attribute value, by one or more space characters. Must be separated from a preceding valueless attribute as well. Why? p title=id=test ... is fine in in HTML. As is the equivalent with ' instead of . Under valueless I mean the case when there is no value, not even an empty one, and no equals sign, like this: input disabled type=text Here, whitespace is required between disabled and type. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] PaceEntryMediatype
On Tue, 05 Dec 2006 00:54:04 +0600, Ian Hickson [EMAIL PROTECTED] wrote: I mean that the feed might contain items that were never part of the page linking to the feed. For example, this page: !DOCTYPE HTML titleFeeds for this site/title link rel=feed href=status.xml link rel=feed href=news.xml link rel=feed href=links.xml pThis page links to the three feeds for this site. There are no items on that page, but it links to three feeds that the site provides. In your example, what's the relation between status.xml and this page? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] References from the spec to wiki pages (was: Provding Better Tools)
On Thu, 07 Dec 2006 06:08:56 +0600, Karl Dubost [EMAIL PROTECTED] wrote: A specification cannot refer to something as volatile as a wiki page. Actually, it's already doing that in another section. http://www.whatwg.org/specs/web-apps/current-work/#other I think it's inappropriate there as well. How can a spec refer to a wiki page which can be edited by anyone and is, in general, out of sync with the spec itself? just as a side note. A traditionnal Web page can be edited as often. But not a spec. Once a spec is officially blessed, it doesn't change anymore (except for changes introduced through some official workflow). Specifications are built on social process and they got their value from and by this social process. It is perfectly fine to disagree with some principles of community building, but not with the nature of the document itself. :) I deeply value the principles of community building, but not when it comes to specifications. I can hardly imagine an implementor monitoring a wiki page and keeping the implementation in sync. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Provding Better Tools (was: Re: 9.1.2.1:trailing slash and atheism)
On Thu, 07 Dec 2006 05:09:44 +0600, Mike Schinkel [EMAIL PROTECTED] wrote: A specification cannot refer to something as volatile as a wiki page. Then have it refer to something less volatile than a wiki page. A section in the spec itself would be just fine. The wiki page could, of course, serve as an intermediate stage where community members make and discuss proposals which later migrate to the spec. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?
On Thu, 07 Dec 2006 05:09:44 +0600, Mike Schinkel [EMAIL PROTECTED] wrote: And if these corporations were using content management systems that didn't produce standards-based code, you can bet those CMS vendors would soon have a new #1 priority, but fast. And THAT would clean up the web quicker than any academic or grass roots effort ever could. Anyway, it's always easy to say something won't work, especially if when no alternate proposals are presented. As I don't work for Google, I'm not in the right position to say what is appropriate for Google to do and what is not. And I'm almost sure Hixie is not in that position eiter. Personally, I would *love* Google to do this sort of thing. I just have no hope for it. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?
On Thu, 30 Nov 2006 03:42:38 +0600, Sam Ruby [EMAIL PROTECTED] wrote: What should be the most damning of all is that I found an example on the most prominent page on the mozilla.org site. No one can say that the authors of that page didn't make a conscious choice in the DOCTYPE for that page. No one can say that the authors of that page are ignorant. No one can say that mozilla has a(n entirely) cavalier attitude towards standards. I was surprised to find the W3C validator consider this page valid. A bug in the validator? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?
On Sun, 03 Dec 2006 10:00:06 +0600, Mike Schinkel [EMAIL PROTECTED] wrote: And as I write this email, it's finally come to me one method that would work for even the most clueless and apathetic of web publishers: What if Google, Yahoo, and Microsoft Live were to display a human-readable string, denoting the content type, hyperlinked to a web page that gives the details of that content type. For example, assume some future version of that the Web Apps current-work page was written in XHTML 1.0 yet it failed the validator; it could look like this (example from Google): Web Applications 1.0 The list of active formatting elements; 9.2.4.3.3. Creating and inserting HTML elements; 9.2.4.3.4. Closing elements that have implied end tags; 9.2.4.3.5. ... whatwg.org/specs/web-apps/current-work/ - Similar pages - XHTML 1.0 (WARNING) An interesting idea, but I don't see how Google would benefit from this. On the other hand, it requires effort, and it would set Google somewhat at war with owners of numerous corporate websites whose image would be spoiled. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Provding Better Tools (was: Re: 9.1.2.1: trailing slash and atheism)
On Tue, 05 Dec 2006 18:14:19 +0600, Mike Schinkel [EMAIL PROTECTED] wrote: The spec shouldn't contain references to implementations. However the wiki should contain such a list (see http://wiki.whatwg.org/wiki/Implementations ). Then minimally the spec should at least contain (something like): Implementors SHOULD NOT use string concatonation and SHOULD use one of the HTML5 components listed here: http://wiki.whatwg.org/wiki/Implementations; A specification cannot refer to something as volatile as a wiki page. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
[whatwg] References from the spec to wiki pages (was: Provding Better Tools)
On Tue, 05 Dec 2006 22:30:36 +0600, Lachlan Hunt [EMAIL PROTECTED] wrote: A specification cannot refer to something as volatile as a wiki page. Actually, it's already doing that in another section. http://www.whatwg.org/specs/web-apps/current-work/#other I think it's inappropriate there as well. How can a spec refer to a wiki page which can be edited by anyone and is, in general, out of sync with the spec itself? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Fri, 24 Nov 2006 09:11:28 +0600, Matthew Raymond [EMAIL PROTECTED] wrote: Second, it contains the word figure, but I think this can be more generic and work for other elements which have %Text attributes. I think we have two separate issues here. You're trying to address a valid concern, but it has nothing to do with figures and figure captions, and there's no reason to avoid markup for figures just because we want to address the limitations of attributes like |title| and |alt|. In your opinion, if %Text attributes (title, alt) in HTML allowed nested markup somehow, wouldn't the title attribute sufficient for fulfilling the use case of captions? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Thu, 23 Nov 2006 18:43:45 +0600, Michel Fortin [EMAIL PROTECTED] wrote: caption a title or brief explanation appended to an article, illustration, cartoon, or poster. If there is a definition in this list which doesn't suggest some kind of visual presentation, it's the caption. Surely you have a different definition than me. I was thinking about a caption as text displayed above/below the figure. In this sense, it's presentational. However, the definition above is semantic. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Wed, 22 Nov 2006 23:52:41 +0600, Steve Runyon [EMAIL PROTECTED] wrote: One minor point I would clarify: Alexey, you stated that label for=XX type=title would replace the title attribute. I assume you meant that it should *supplement* it, since you wouldn't want to preclude its use or mess with backward compatibility. It would replace the title attribute from the semantic POV only. For example, various semantic extractors which know about label type=title should use its content instead of the title attribute when they need to know the title of something. For those which don't yet know about label type=title, the title attribute will provide reasonable fallback. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Thu, 23 Nov 2006 03:27:31 +0600, Henri Sivonen [EMAIL PROTECTED] wrote: label for=fig1 type=title.../label label is not good, because it is reasonable to style form control labels the way the platform styles labels, but the styling may not be appropriate for figure captions. Also, the for attribute is now supposed to refer to a form control. I agree that reusing label can cause problems, so I'd like to find a brand new name, too. I think it is better to introduce a figcaption or something than to confuse what label is. I don't like figcaption for two reasons. First, it contains the word caption while I propose using the new element in title, alt, and label roles at least. Second, it contains the word figure, but I think this can be more generic and work for other elements which have %Text attributes. Maybe title-text, alt-text and label-text for each of the three purposes? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Tue, 21 Nov 2006 10:30:17 +0600, Matthew Raymond [EMAIL PROTECTED] wrote:
There are W3C guidelines that say that UI in user agents should
follow the UI conventions of the underlying operating system. This is
what caused the demise of general focus passing for label elements
(which was specified in HTML 4.01). As of WF2, label elements only
pass focus if labels would normally have focus passing for that kind of
control in the user's OS. (I called it an irrational consistency, but
I was overruled.)
Let's not think of label with type attribute or any other element which is
introduced instead as of a visually element. It should be just a way of
expressing the value of title, alt etc with rich markup inside.
I don't necessarily have a problem with supporting rich tooltips, but
my main concern is that there isn't much of a use case for it, it won't
match UI conventions for most platforms, and fallback is a nightmare.
Looking at the number of JS libraries implementing tooltips with rich markup,
I can say there's plenty of a use case.
With regard to fallback, think of how your above example would render
if the CSS file failed to load or wasn't supported. It would probably be
something like this:
Here is a backward compatible example of markup:
label[type=title] { display: none; display: tooltip }
img id=img1 src=... title=My lovely kitten
label for=img1 type=titleMy stronglovely/strong kitten/label
1. Today's UAs will ignore display: tooltip and apply display: none to the
label element.
2. Future UAs will honor display: tooltip, and the content of the label
element will be shown in a tooltip for the image, overriding the tooltip which
would be shown otherwise (the value of the title attribute).
3. Semantically, the title of image is considered to be My
stronglovely/strong kitten -- with rich markup inside.
For various popup purposes I have added popup element that is
display:none normally and has better semantic meaning so
we use popups for such tooltips in almost all cases.
I believe that popup would be as presentational as center. The semantics of
my proposed markup is that the fragment of rich text within label is
considered the title, alternative representation, etc of the referenced
element, overriding the corresponding attribute of that element. The rule that
label type=title should be displayed as a tooltip should be expressed by a
stylesheet.
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] (IMG / CAPTION discussion)
On Mon, 20 Nov 2006 07:44:07 +0600, Scott Tankard [EMAIL PROTECTED] wrote: img id=img1 src=... title=... That is, an image with a tooltip. While this does contain the wanted benefits of nested elements, the obvious increase in sheer size (a bone for those who type their code without automation) is coupled with the difficulty of matching the tooltip with the element it describes. May I suggest: img id=img1 src=... tip.../tip /img Unfortunately, you can't do that with img in HTML without breaking the parsing of existing pages. Also, I believe this should be title, not tip. The semantics of the markup is that the text is the title of the image, and the desire to dipsplay it as a tooltip is presentational. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
