[whatwg] select required
I just read Hixie's message here:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017583.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017583.htmlWhile
I understand the reasoning for not implementing a bunch of new attributes
and functionality, I would still like to see select required even without
the other suggestions as requiring at least one option element to be
successful with a non-empty value.
I was beginning to write a form for a site and I thought I'd go ahead and
use input required and textarea required with some css:
[required] ~ label:after { content: '*' }
... and possibly javascript to read that attribute, etc.
But since I can't implement that on my select elements and still validate,
I plan to skip the required attribute entirely and use class names instead
for now so that all the form elements are consistent.
--
Jon Barnett
Re: [whatwg] Sort child nodes of a DOM node.
On Fri, Jun 4, 2010 at 1:49 AM, Biju bijumaill...@gmail.com wrote:
There are many cases where we want to sort child nodes of a DOM node.
Many times it is TR nodes of a TBODY
Right now user writes javascript code to achive that.
Dont you think it is better if there was built DOM method for each node.
Additionally the method will have a sort function parameter to compare
elements
the same way as in JavaScript Array.sort(compare_func)
function compare_func(a,b){
if(isHeaderRow(a)) return -1;
if(isHeaderRow(b)) return 1;
if(a.textContent == b.textContent) return 0;
if(a.textContent b.textContent) return -1;
return 1;
}
tablebody.sortChildNodes(compare_func)
Use cases:-
Example 1: column sorting in yahoo mail
Example 2: you can sort this listing by clicking the column headers
https://bugzilla.mozilla.org/buglist.cgi?short_desc=sortshort_desc_type=allwordssubstrresolution=---
Example 2: there are bug report in mozilla asking sorting in XUL grids
https://bugzilla.mozilla.org/showdependencytree.cgi?id=482890hide_resolved=1
This sounds more akin to the thread with the subject line Adding ECMAScript
5 array extras to HTMLCollection
It's already easy enough to do once you've copied the nodes into an array:
var rowsArray = convertNodeListIntoJSArray(tBody.rows); // assuming you've
written such a function
rowsArray.sort(compare_func);
tBody.innerHTML = ;
rowsArray.forEach(function(row) { tBody.appendChild(row) });
I'd rather just see some kind of resolution to mixing in Array methods into
the HTMLCollection object. Since HTMLCollection objects are often 'live' it
would just be:
tBody.rows.sort(compare_func);
I have no opinion on how Array methods should be mixed into HTMLCollection
objects, since the difficulty seems to be more in implementation than
devising a web authors' wishlist, but that's what I'd rather see.
--
Jon Barnett
[whatwg] Timers
Do setTimeout and setInterval belong in HTML 5? They're not really DOM related. They're supported by ActionScript, which doesn't have a DOM. AS supports the same signatures that HTML 5 does (plus another one). HTML 5 already says they're specific to Javascript/ECMAScript, so there's no need for other DOM implementations to support them. I searched the ES5 final draft and didn't see a reference to them anywhere. Have they been considered for ECMAScript 5 or any version? I didn't find any discussion in the WHATWG archives. http://www.adobe.com/support/flash/action_scripts/actionscript_dictionary/actionscript_dictionary646.html -- Jon Barnett
Re: [whatwg] cross-domain scrollIntoView on frames and iframes
On Mon, Apr 6, 2009 at 3:51 PM, Jonas Sicking jo...@sicking.cc wrote: From my point of view I'm not sure how interesting this whole feature is. We had support in firefox for XPointer for many years and saw little to no uptake. I'm not sure if anyone complained when we removed the support even (which would be pretty remarkable). / Jonas Was it advertized? I follow Firefox closely enough, but I don't remember when XPointer was supported. Was it supported by other browsers? It would be rare in the wild if it's only supported by Firefox. Do other browsers have easy scripting support for XPath? Except for the cross-domain iframe case, you could script support for XPointer if the browser has decent support for XPath in Javascript. I know I've had instances where I wished for XPointer support. It may or may not have had a fair shake. -- Jon Barnett
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
On Thu, May 15, 2008 at 1:23 AM, Boris Zbarsky [EMAIL PROTECTED] wrote: Samuel Santos wrote: I don't think this is a valid argument since you can change it anyway [1]. [1] http://www.quirksmode.org/dom/inputfile.html I should note that some consider this a (low priority, low severity) security bug that should just be fixed (e.g. by disallowing opacity styling on file inputs or some such). -Boris The Yahoo! UI toolkit [1] allows a developer to create a browse that looks like whatever he wants it to and can be controlled by javascript pretty much however he wants it to. Flickr uses this (you have no log in, so no link here). It also has more robust features than input type=file - the interface can have custom styles - the dialog can choose multiple files - the dialog can filter certain file types That Yahoo widget uses Flash and Javascript to make all that happen. Adobe isn't going to take this feature of Flash away (Javascript control of a file dialog) and I wouldn't expect browsers to try to block it. The W3C File Upload [2] draft allows for the something similar using plain javascript without the requirement for Flash, and there are already implementations in the wild. That's just a generic Javascript API - I can't imagine browsers trying to restrict how that looks on the page. Again, - the interface that have custom styles (anything with an onclick will do) - the dialog can choose multiple files These aren't features you're going to take away from today's users of popular web applications. Those features are here to stay. I don't see how customizing the look of the file dialog's button is a security risk. Sure, the button might say something malicious, but it still requires the user to browser his local files, choose a file, and click Open. One problem with either the Yahoo widget or the File Upload draft is that they both require Javascript to function. If you want these features to be accessible to non-Javascript enabled browsers, we'll need to include it in HTML. It would probably call for a new input type with a more specific, flexible presentation (i.e. just a button that can be styled with CSS) If Javascript is as an acceptable requirement, another problem with those solutions is that they require separate POSTs. The Yahoo uploader uses a separate request for each file. The File Upload API has functions like getDataAsHexBinary that, I guess, could put a file's data into a hidden input field, but that data still wouldn't be uploaded the same way regular input type=file is uploaded (as multipart/form-data with headers for each file, etc). It would be better for HTML to specify an accessible and clean way of styling buttons for producing file dialogs than to force Samuel Santos to use dirty CSS hacks, a proprietary tool, or an API that interfaces with HTML forms in a clunky way. [1] http://developer.yahoo.com/yui/uploader/ [2] http://www.w3.org/TR/file-upload/ -- Jon Barnett
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
On Thu, May 15, 2008 at 5:04 PM, Matthew Paul Thomas [EMAIL PROTECTED] wrote: Imagine that there is a popular mobile device with a Web browser. Imagine further that this browser is widely used, despite having no support for Flash, no support for W3C File Upload, and not even any support for input type=file. I know, I know, this seems unrealistic, because those features are here to stay, but humor me here for a moment. For ease of discussion, let's call this device the iPhone. Except for the needless sarcasm - we're on the same page here. Imagine further that this iPhone has no user-visible file system. It stores music, but annoyingly, the device vendor doesn't want to let people upload songs to Web sites. What the vendor *does* want to let people do is upload photos to Web sites, so that they can use sites like Flickr or even post photos to their Weblogs from the road. So the iPhone vendor implements input type=file just for photos. Is this the iphone's behavior? (earlier you said it doesn't implement input type=file, but here you're saying it's implemented for photos) It's rendered in a Web page as three components: (1) a button for taking a new photo, (2) a button for choosing an existing photo, and (3) a thumbnail of the selected photo. There's no filename: that wouldn't make any sense, because device has no user-visible files. The interface for choosing a file isn't particularly important. It's the style/presentation of the button that triggers that interface that's in question, or being able to create your own interface to trigger that file-choosing interface. It's a security risk in those browsers where input type=file contains an editable text field, because a page could trick you into typing the pathname of a confidential file into the field, and the button would no longer warn you that it wasn't an innocent text field. In browsers (such as Firefox 3, as Jonas just mentioned) where the field is not editable, the button is safer to style -- but if you're assuming the control contains only one button, you might produce ugly results on devices where it has more. Sure, we agree that tricking a user into typing a filename is somewhat of a security risk, and browsers have mitigated that. My point was disguising the button that triggers the file-choosing dialog box (or web-page-like interface, if you will) is NOT a security issue. It's very possible to create a custom interface for triggering that dialog, but all the solutions I know of are convoluted and don't interface well with web forms. For example, if I want just a plain blue, underlined link (a la Flickr, click here to upload your photos) to trigger that browse dialog, I have to use something like Yahoo's widget or the File Upload API. Or, I have to use CSS hacks that are probably going to look silly on an iPhone. I only have a couple possible solutions in mind: - Insist that input type=file always be rendered like input type=button and therefore can be styled as such. That's not such a great solution for lots of reasons. - Insist that the HTMLInputElement.click() method in Javascript trigger the UAs file-choosing dialog. I don't know any browsers that support that, you know, for security reasons - never mind that there are two other ways to already do that with Javascript today. That would require Javascript to function, but at least it degrades more gracefully than depending on Flash or the File Upload API just to have a custom button. The HTMLInputElement would stay intact, so you don't have to code two or three separate methods of handling file uploads (see my note about separate POST requests, etc.). Plus it would be more feasible on a device like the iPhone that may not support a whole new complex API (and may never get Flash). So, is there any reason for browsers to NOT support HTMLInputElement.click() to trigger a file dialog? Is it reasonable to insist that they do? Would that solve Samuel Santos' original concern for wanting a custom, localized button that says Upload a file in his site's native language? ... If Javascript is as an acceptable requirement, another problem with those solutions is that they require separate POSTs. The Yahoo uploader uses a separate request for each file. The File Upload API has functions like getDataAsHexBinary that, I guess, could put a file's data into a hidden input field, but that data still wouldn't be uploaded the same way regular input type=file is uploaded (as multipart/form-data with headers for each file, etc). ... Web Forms 2.0 already defines min= and max= attributes for this purpose. Thanks, I hadn't seen that. input type=file max=n where n is greater than 1 would allow for mutliple files. I hadn't seen that. -- Jon Barnett
Re: [whatwg] Referer header sent with a ping?
On Feb 2, 2008 8:59 PM, dolphinling [EMAIL PROTECTED] wrote: Cookies and authentication headers I'm ambivalent about; no one's made a persuasive case either way for them, and I haven't looked myself. dolphinling http://dolphinling.net/ The ability to log pings according to session data would be important to me. That can be done without cookies, but not very conveniently. I guess the same applies to authentication headers, though I rarely use them. But yes, relating a ping back to a specific user is useful. Since cookies and authentication headers are something I can do without @ping, I think it would be a necessary feature to compel me to use @ping. -- Jon Barnett
Re: [whatwg] validate attribute in A
On 11/5/07, Ian Hickson [EMAIL PROTECTED] wrote: Philip brought up a good point on IRC which is that hashing the entity doesn't protect against changes to the headers (and hashing the headers isn't workable since they change). I'm not sure it's worth it. Those are good use cases, though. If it were to be crammed into HTML, it would be nice if it were done like this: a href=... type=application/octet-stream; md5=xxx That may not work, though, if it steps on RFC1864's toes. -- Jon Barnett
Re: [whatwg] successful form controls
On 9/15/07, Kristof Zelechovski [EMAIL PROTECTED] wrote: 1. Radio buttons are never checked so this sentence means that they are never successful. The selected radio button in a group is checked - even thought it doesn't look like a checkmark, yes, it's checked. 2. A control that is read-only does not accept input from the user; however, it may have a meaningful value that is worth submitting because its value can be calculated on the client side. Indeed, readonly controls should be successful. (Yes, they are in HTML4 as well) -- Jon Barnett
Re: [whatwg] getElementsByAttr
On 7/6/07, Sander [EMAIL PROTECTED] wrote: Hello, I'm not sure if this has been proposed yet (can hardly believe it hasn't). But I couldn't find it in the specs so I just give it a go anyway. I'd like to see a getElementsByAttr method. It would be quite similar as the getElementsByClassName method but with an extra argument: getElementsByAttr(attribute_name, value) For attributes that can have more than one value (either seperated by spaces or commas) the value argument may be a space(/comma) seperated string or an array, similar to getElementsByClassName. If value is not defined of perhaps a wildcard (*) the method should return all nodes that have the particular attribute, no matter what its value is. The method overlaps with both getElementsByClassName, getElementsByTagName and getElementById, as these filter on attribute value as well, but it still adds extra opportunities. cheers, Sander I personally prefer the DOM 3 XPath evaluate() method, which is implemented at least by Mozilla on the document object. Not sure about other UAs. However, AFAICR, XPath doesn't meet all use cases, such as space-separated token lists, like @class. http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html#XPathEvaluator http://developer.mozilla.org/en/docs/DOM:document.evaluate Since these APIs are spread out over various specifications, it's hard to guess what common browsers are going to support in the future. It would be nice if HTML5 informatively notes these other APIs that may be supported (XMLHttpRequest also fits in this category) -- Jon Barnett
Re: [whatwg] void elements vs. content model = empty
On 6/20/07, Jonas Sicking [EMAIL PROTECTED] wrote:
Simon Pieters wrote:
FWIW, script src has empty content model but still requires the end
tag.
That is not true. The contents of a script src is interpreted as
script and executed if loading the resource pointed to by the
src-attribute fails. In other words
script src=http://nonexistant.example.com/;
alert('hi');
/script
should bring up an alert.
/ Jonas
That's not what section 3.17 currently says, and that's not the way Firefox
behaves on my machine. Is that noted anywhere?
--
Jon Barnett
Re: [whatwg] P element's content model restrictions
On 5/29/07, Anne van Kesteren [EMAIL PROTECTED] wrote: I don't care much for the semantic side of things but changing section 8.2 (and Acid2) to make ptable not become p/ptable as per HTML4 would be fine with me. We discussed this recently in #whatwg. Simon has some ideas about it. Is there a link to any of this discussion? I imagine my searching for p or p element might be futile. Given: pThis is a lengthy paragraph that talks about the following table table... Breaking scripts that depend on p.nextSibling to be the table and styles that depend on p + table to work (and other various DOM issues) is an obvious point, and I'm sure it's been discussed.
Re: [whatwg] Style sheet loading and parsing (over HTTP)
On 5/24/07, Gervase Markham [EMAIL PROTECTED] wrote: Jon Barnett wrote: It's detrimental to the user when the user is denied content or a stylesheet for the content because a server is misconfigured. There are cases, such as CSS documents and images referenced by CSS documents, where ignoring Content-type is never harmful. in other cases, the harm can be mitigated by the rules in the spec. It's also detrimental to the user when they are put at security risk because MIME types are not respected. Recent example: spammers, phishers and other sundry evildoers have started attaching HTML attachments to Bugzilla installations, and using them as redirectors to their sites, to avoid domain name blacklists in spam filtering software. Obvious solution: if an attachment is uploaded by a user with no permissions and its MIME type is one which contains script executed by the browser (all HTML types, SVG, ...) then change it to text/plain. This is the least intrusive option - the attachment can still be viewed, and someone with permissions can change the MIME type later after checking the content. However, this doesn't protect anyone using IE, because IE claims to know better and ignores Content-Type. Gerv if I read the current draft correctly, that resource should still be sniffed as text/plain. That's what I meant by the harm can be mitigated by the rules in the spec. I would propose that the type attribute be more meaningful on, for example, the a element and the object element: - If the type attribute is present, the UA must use its value as the value of the Accept request header when requesting a resource And then apply sniffing rules that take the Accept request header into account (including wildcards in the Accept header): - If the Accept request header accepts text/plain and not text/html, and the Content-type response header is text/plain, it must not be sniffed as HTML. - If the Accept request header does accept text/html, and the Content-type response header is text/plain, it may be sniffed as HTML. That would allow, for example, Bugzilla to use a type=text/plain when linking to an attachment without fear that the attachment might be sniffed as text/html. I don't know how that would break existing content, but I did want to mention it. I don't think the type attribute is currently abused, especially on links, in a way that would make this harmful. -- Jon Barnett
Re: [whatwg] Style sheet loading and parsing (over HTTP)
On 5/23/07, Julian Reschke [EMAIL PROTECTED] wrote: Ian Hickson wrote: On Wed, 23 May 2007, Julian Reschke wrote: http://lists.w3.org/Archives/Public/www-tag/2006Aug/0027.html Actually, I wasn't planning to. I think that that finding is a good one, and that we should work on making less content break it. I recommend reading the first of the two links cited above. It describes what I did to work on making less content break it, and why I think that it's a lost cause. Actually, I read those messages when they were written. Ok, then you know that I have attempted to do the work you propose we do. What more work can we do? For instance, continuing to allow UAs to trust the mime type, and requiring content authors to send the proper mime types. Or, allowing (opt-in) browsers to flag broken media types in the UI, as suggested in http://lists.w3.org/Archives/Public/www-tag/2006Aug/0035.html (yes, same thread). * I do understand that there's a gap between what the specs say Content-Type should do, and what works in reality. Indeed. And the specs, to be useful, have to match reality. That may be true if all we're discussing a spec that defines what a UA has to implement to be compatible with today's broken content. I absolutely agree that it's good to write that spec, but I disagree that this should be same spec as HTML5. * As we just saw with the XSLT example, making generalizations like in Anne's proposal is dangerous: for instance, Mozilla does check the content type of XSLT style sheets, and it seems people can live with that. In this particular case, XSLT content was served with type text/html, and when the problem was discovered, the author immediately fixed the server config. The HTML5 spec requires that Content-Type headers be obeyed everywhere where I could possibly get away with requiring it. It only ignores it where reality requires it. Let's look at an example. http://www.whatwg.org/specs/web-apps/current-work/#the-img currently states: The remote server's response metadata (e.g. an HTTP 404 status code, or associated Content-Type headers) must be ignored when determining whether the resource obtained is a valid image or not. This allows servers to return images with error responses. User agents must not support non-image resources with the img element. Issues I have with this: - it doesn't provide tell content authors that the content-type header *should* reflect the mime type; instead it suggests it doesn't matter, - it disallows UAs to trust the mime type, as recommended by other specs, - and finally it even requires UAs to ignore the HTTP status (which IMHO is even worse than the Content-Type issue). * I think it would be bad if the W3C TAG finding on media types and a future W3C HTML spec would contradict each other. It would be worse if reality and the future HTML spec contradicted each other. (It is already quite bad that the TAG finding contradicts reality.) Well, I disagree. The TAG finding says how things should work. If you think that this is wrong, you'll have to try to change *that* (I know you tried...), but just ignoring it in a W3C spec is unlikely to be accepted. Can someone point out specifically how HTML5's section on error handling contradicts this TAG finding, especially sections 4 and 5? It says: Web agents SHOULD have a configuration option that enables the display or logging of detected errors. Obviously users don't want to see an alert every time an HTML page is served as text/plain, but if the UA logs that error or displays it plainly somewhere like Firefox's Page Info dialog, that should be enough. It also says: An agent MUST NOT ignore or override authoritative metadata without the consent of the party employing the agent. A UA could simply keep a preference in the UA's advanced options where this is enabled by default. It should be possible for a UA to satisfy both of those conditions and still do the content-type sniffing in HTML5. Also, HTML5 doesn't encourage authors to use incorrect content-type, it just suggests how browsers should handle errors. (sorry I didn't hit reply to all the first time...) -- Jon Barnett
Re: [whatwg] Style sheet loading and parsing (over HTTP)
An agent MUST NOT ignore or override authoritative metadata without the consent of the party employing the agent. is a good thing, but please don't claim by having this default to true constitutes consent. Best regards, Julian Prompting a user for any sort of consent would be useless and confusing, because users don't know what MIME types are. Even a dialog that says This document claims to be plain text, but looks like a hypertext document. Do you want to render it as a hypertext document? would be useless and confusing because, frankly, users don't know the difference between plain text, web pages, and Microsoft Word. So, if you interpret that consent to mean some sort of explicit interaction by the user after the User Agent is installed, then that clause is impossible to satisfy in any useful way. For the purpose of this discussion and this section of HTML5, consent should be defined as Anne said - by using a browser, you consent to it being useful. But there's an option to make it less useful if you want. Logging Content-type discrepencies in an error console should be enough to satisfy the other requirement in section 4. I understand your concern. You want authors to correct mistakes in their code (and server configurations) to comply with standards. Authors should be encouraged to do so, but only in ways that are not detrimental to end users. End users don't make a good middle man for telling an author when his code doesn't agree with a spec. End users tend to blame the browser first. -- Jon Barnett
Re: [whatwg] Style sheet loading and parsing (over HTTP)
On 5/23/07, gary turner [EMAIL PROTECTED] wrote: Absolutely. Authors and server admins have the responsibility to get things right. What I do not understand is how having a browser follow the rules is detrimental to the user. On the contrary, ignoring the server or meta content-type is harmful. Others have cited examples. It's detrimental to the user when the user is denied content or a stylesheet for the content because a server is misconfigured. There are cases, such as CSS documents and images referenced by CSS documents, where ignoring Content-type is never harmful. in other cases, the harm can be mitigated by the rules in the spec.
Re: [whatwg] Predefined classes are gone
There are various possible solutions to replace error and warning, some of which include the following. (This is just brainstorming, neither of these are particularly well thought out ideas.) 1. New attn element (short for 'attention'), which is specifically for attracting the users attention, which is exactly what errors and warnings do. 2. A new attribute on label to associate it with a related error message. e.g. label for=ctrl attn=ctrl-errorFoo/label input id=ctrl span id=ctrl-errorYou filled in an incorrect value/span The attn element is more generic and could probably solve other similar use cases, whereas the the label attribute would only specifically solve the form error use case. -- Lachlan Hunt http://lachy.id.au/ I like the idea of an attn element more than the other given ideas for associating a message with a form or form control. It should have a for attribute, like label: label for=passwordEnter your new password/labelinput id=passwordattn for=passwordYour password is too short/attn In combination with a role attribute, it would solve issues with form controls: label for=passwordEnter your new password/labelinput id=passwordattn for=password role=errorYour password is too short/attn An attn can attach to form and fieldset elements as well. form id=loginattn role=error for=loginLogging in was unsuccessful/attn.../form There might be a use case were attn might be able to attach to other non-form elements. I can't think of a compelling one. (The idea of an attn attribute above leaves the error message twice removed from its form control) I like the idea of a role attribute for reasons other than that it's new and doesn't conflict with exiting class attributes. Authors assume that the class attribute is theirs to use for scripting and styling without outside interference from the UA. Author's don't assume this about the rel attribute. Authors assume that the UA will assign meaning and function to the rel attribute, such as rel=next. HTML4 leaves the possible values for rel open-ended, but authors don't use it willy-nilly. However, rel=nofollow exists because UAs decided to support it. role should have the same type of existence. I don't think XHTML2's example values for role are useful (except note and search). error and warning are good useful examples. In the same vein, I would add confirmation or success. -- Jon Barnett
Re: [whatwg] Sandboxing ideas
On 5/15/07, Kristof Zelechovski [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. Chris I really think comments are a bad use case. Why would someone allow scripts in comments in any context, much less a sandboxed one? 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.
Re: [whatwg] Sandboxing ideas
On 5/14/07, Michel Fortin [EMAIL PROTECTED] wrote: Le 2007-05-14 à 11:35, Alexey Feldgendler a écrit : 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.
Re: [whatwg] Sandboxing ideas
On 5/8/07, Henri Sivonen [EMAIL PROTECTED] wrote: On May 8, 2007, at 19:32, Dean Edwards 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 wonder if this issue could be solved on the layout/CSS level by providing a way to make the height of an iframe depend on the actual height of the root element of the document loaded in the iframe. That is, would it be feasible to make the iframe contents have the layout/ UI feel of a part of the parent page while keeping the DOMs and script security contexts separate? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/ http://www.w3.org/TR/css3-box/#intrinsic0 (and also CSS2 10.6) Since CSS doesn't attempt to specify the intrinsic width of a document in an iframe, maybe HTML5 should specify that the intrinsic width of a document is: - if the CSS width property is specified on the html element, the margin-box of the page at that width (which may have overflow) - else, if the CSS min-width property is specified on the html element, the margin-box of the page at that width (which may have overflow) - else, the smallest width the page can have without horizontal scrolling and the intrinsic height of the document is: - if the CSS height or min-height property are set, similar to above, - else, the smallest height the page can have at the intrinsic width of the document without vertical scrolling -- Jon Barnett
Re: [whatwg] style='' on every element
# # [19:40] Hixie hsivonen: so, my requirements for the font/ style= thing is that style= not be allowed everywhere, since that encourages media-specific markup. A style attribute that includes media-specific properties (page-break-after, voice-family) still works as expected. The only thing style doesn't provide is to apply non-media-specific attributes in a media-specific way (applying a border to screen media and not print media). That's a rare use case. Is this spec dead? http://www.w3.org/TR/css-style-attr Would/could that spec allow @media rules within the style attribute? It apparently allows @include rules. It's a 5 year old draft, but it looks useful. Yes, I understand its functionality is covered by local style elements Does HTMLElement still implement ElementCSSInlineStyle from DOM Style 2? someelement.style is very popular in Javascript, and I don't see a compelling reason to remove it if it is being removed. It's worth nothing how browsers currently handle setting a property using someelement.style: someelement.style.border = 1px solid; alert(someelement.parentNode.innerHTML); IE, Firefox, and Opera all show the border property as part of the style attribute (even if the style attribute wasn't already set). Firefox uses the border property, IE uses border-left, border-right, etc. Opera doesn't use any shortcut properties and uses border-left-style, etc. Konqueror does apply the border, but doesn't reflect that property in the innerHTML. I'm not sure how important any of this is. -- Jon Barnett
Re: [whatwg] font (was Support Existing Content)
The current phrasing doesn't restrict this to span. It allows WYSIWYG editors to produce pfont size=7blah/font/p where h1blah/h1 is appropriate. If I understand correctly, even that wouldn't be correct, because the only attribute specifically allowed on font is the style attribute. I don't personally know of any WYSIWYG editors that use font style. I know of some that use font color and font size as well as span style and even big and small, but none that use font style by default. As it is, it looks like the spec is trying to be backward compatible with something, but I don't know what. If font is allowed, then font size could be allowed, because a server-side script could more easily find font size=7 and replace it with h1. Since I'm not aware which editors are being graced by allowing font without size or color. Hopefully before editors start putting an HTML5 DOCTYPE on HTML files, they'll stop using font in favor of something else. Until then, they can happily put HTML 4.01 Transition (not even Strict!) on their documents that include font
Re: [whatwg] additional empty elements
If you're marking up stuff as a tree, the markup should probably look like a
tree:
section id=treeFirst group
divSecond Group
divThird Group/div
/div
/section
if what you want it a tree, that structure is better, so the CSS would
simply say:
#tree, #tree div { margin-left: 5em; }
If you want to style each level differently, that's still easy to do without
making up class names:
#tree { background: blue; }
#tree div { background: green; }
#tree div div { background: yellow; }
Child selectors are not supported by IE6, but I believe they are by IE7 and
every other browser.
Re: [whatwg] font (was Support Existing Content)
Embedded and inline editors would include the textarea tag, which is clearly not WYSIWYG for HTML (but is for plain text) so both are poor terms. Embedded, inline editors would include contenteditable areas and documents with designMode on, like the box I'm typing in right now in Gmail. Quite a number of the cheap HTML to PDF conversion processes don't support CSS. Additionally, syndicated HTML (via Atom, RSS etc) tends to have inline CSS removed because of cross site scripting vulnerabilities (you can embed JavaScript in CSS and at least IE will execute it). It's not so much cheap as lightweight. A heavyweight converter can automate the process of opening a page in a browser window, print what's in the browser (more or less, some do more than just activate the browser's print function). A lightweight converter might natively try to interpret the HTML and try to render it as postscript. I think better solutions are coming along for the case of converting an HTML document to PDF in all its graphical glory on a server without X Window, etc. (e.g. a way of using Gecko to do the work without opening a window.) I don't think it's necessary to cater to these systems by allowing presentational markup.
Re: [whatwg] Drag'n'drop uploads propsal
On 4/30/07, Ian McKellar [EMAIL PROTECTED] wrote: On 4/25/07, David Hyatt [EMAIL PROTECTED] wrote: The use case of being able to drop images into a contenteditable region and have them show up as img elements at the appropriate place and then get automatically uploaded somewhere is a really compelling one. Is there already an API for knowing exactly where something is dropped? Possibly - an empty Range object as either the relatedTarget or part of the detail of a drop event.
[whatwg] sarcasm
I think sarcasm is a good case for class extensions http://wiki.whatwg.org/wiki/ClassExtensions That could also apply to other tones of voice where context doesn't make it obvious, such as irony, anger, suspicion, elation, and veiled threats.
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On 4/22/07, Kornel Lesinski [EMAIL PROTECTED] wrote: On Sun, 22 Apr 2007 01:26:55 +0100, Jon Barnett [EMAIL PROTECTED] wrote: By entirely omitted alt, do you still only mean WYSIWYG editors? If not, I agree. The distinction would be as follows: (1) img src=obvious.jpg alt=obvious - This image represents text, particularly the word obvious. Lynx should replace it with the word obvious and do nothing else. (2) img src=gallery2.jpg The image is part of the content and doesn't represent text. Lynx should indicate that the image is missing and offer a way to download it I'm a bit worried about this one - authors too often forget (or don't care) to add alt attribute, and this case gives it a different meaning. I think that for (2) there should be either magic alt value or some way of specyfing that alt was intentionally omitted, and not forgotten (special classname? presence of title attribute?). -- regards, Kornel Lesiński The rel attribute isn't specified for the img element, but this might be a good use for it - what relationship does this image have with the document. Thoughts on that, or something new? If the alt attribute is required, what should it be for (2)? Blank? A paragraph describing the vista of the Grand Canyon?
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
When screen readers find img without alt, there typically attempt to fake alternative text using the src attribute. This can be done crudely (just reading the whole path) or selectively (just reading the filename, e.g. gallery2.jpg). Since authors will continue to fail to provide alternative text, screen readers are likely to continue employing such heuristics, defeating any attempt to attach a special new meaning to missing alt attributes. If images without alt are to be allowed, then noalt would be a reasonable hint. -- Benjamin Hawkes-Lewis When UAs do what you describe, do they provide a way to download the image (text browsers) or indicate that what's missing in an image (screen readers)? What UAs? Is this different from how they currently behave when alt is present but blank? This page: !DOCTYPE html titleIMG test/title ol liImage represents a img src=PICT0023.JPG alt=tree liImage is content img src=PICT0023.JPG liImage is decorative img src=PICT0023.JPG alt='' /ol Is rendered by Lynx (on my machine) as: 1. Image represents a tree 2. Image represents is content [PICT0023.JPG] 3. Image represents is decorative Only in (2) does Lynx indicate that the image is missing. That's the behavior I would expect (even with noalt) Neither Firefox nor Konqueror distinguish between (2) and (3) with images disabled. noalt is a good idea and leaves no ambiguity. The current draft does say that a missing alt should be treated as if it's blank. Should that stay the same, or should special semantics be defined for a missing alt? Would any new semantics affect the DOM alt attribute? (I don't think it should.) I'd still like to know what other current UAs (screen readers) do with a missing alt. -- Jon Barnett
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
Options might include image 2 - vista of the canyon or image 2 (where the text already says what that is) or all kinds of other things. noalt is a good idea and leaves no ambiguity. Except that it breaks all backward compatibility. Can you please explain how? img src=grandcanyon.jpg alt=image 2 - vista of the canyon doesn't help the ambiguity. img src=grandcanyon.jpg title=image 2- vista of the canyon is more appropriate. The image does not represent that text, that text describes the image. The difference may seem subtle, but there is a difference. img src=rssicon alt=RSS is a case where the text serves no purpose than to represent the text RSS. Lynx can happily replace the image with the text as if the image doesn't exist. In the grand canyon example, Lynx should at indicate that the image does exist. This difference may be minor, but HTML doesn't explicitly tell authors how to mark up images that don't actually represent text and it's a distinction authors want to make. If noalt isn't acceptable, then let me suggest the rel attribute (with a couple suggested values). If the rel attribute was allowed on the IMG element, it could tell the relationship of the img to the document
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
/#inserting3property. (In CSS2, content only applies to :before and :after). This is the best solution as the image can be allowed to scale if its scalable, doesn't conflict with (1) and (2). However, browsers don't support this well (if at all), and that's a W3C Working Draft that hasn't been touched in 3 years. (I'm just a peon developer, so I don't know anything about that WG.) Current browsers be damned, this is what HTML5 should specify (explicitly, so there's no confusion between this and (1) and (2)). Without damning current browsers, something would have to be specified that's distinguishable from (1) and (2). to summarize: For (2), I recommend making the alt attribute optional. Alternatively, HTML5 could specifiy that (2) should have an alt attribute that is blank, but I think this leaves too much ambiguity. (What if there's an image that represents text, is also accompanied by that exact same text, making the alt attribute redundant. Leaving alt blank helps here.) For (3), I recommend that HTML5 say something about the CSS3 content property so there's no question that (3) is different from (1) and (2). If compatibility with today's browsers is more important, then I don't have a quick answer (maybe rel=decoration?) Hope this sums up the issue well for the sake of discussion. -- Jon Barnett
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On 4/21/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: How is an object with empty fallback content different from an img with an empty alt value? It seems like it is just as ambiguous, since if the fallback content were non-empty it should be substituted. I guess made an assumption that object semantically means embedded object that is part of the page content while img semantically means image that represents text, making the distinction between (1) and (2). Although, like I said, I think omitting the alt attribute is a better way to distinguish (2) from (1) I think a better option would be to distinguish alt=, and use that for images in the content that add no meaning as the draft says today, and no alt attribute at all for images that are meaningful, but where a text description is not available or appropriate. That's pretty much what I said at the end of the message, so I agree. We could limit img with no alt attribute to content generated by WYSIWYG editors, in the same way as font. Or something like that. That's where I disagree. I think it should be perfectly valid for authors to omit the alt attribute on images in a gallery for the same reason it's acceptable for YouTube not to have fallback content for its videos in embed tags. This does not just apply to WYSIWYG editor. Basically we can distinguish the two cases by alt= and entirely omitted alt. Regards, Maciej By entirely omitted alt, do you still only mean WYSIWYG editors? If not, I agree. The distinction would be as follows: (1) img src=obvious.jpg alt=obvious - This image represents text, particularly the word obvious. Lynx should replace it with the word obvious and do nothing else. (2) img src=gallery2.jpg The image is part of the content and doesn't represent text. Lynx should indicate that the image is missing and offer a way to download it (3) img src=decor.jpg alt= The image is purely decorational or represents text that would be redundant to display. Lynx should pretend it's not there. -- Jon Barnett
Re: [whatwg] Web Documents off the Web (was Web Archives)
On 4/17/07, Thomas Broyer [EMAIL PROTECTED] wrote: I hope you're talking about GZip or BZip2, not application/zip… Doesn't matter to me - I just figure some sort of compression would help, and it would probably help if that compression was supported by browsers, so gzip sounds right. The problem is the current browser support for .mht and support for generating/loading .mht files with binary attachments. Which appears to be halfway there in the major browsers. The method for reading Web pages off line is subscription, not downloading. Your browser should support subscription. Enable it for your favorite pages and you are done. Maybe in your browser, but not store on disk apart from your browser, and not to transfer to someone else (via email, web download, p2p) as a self-contained document (e.g. a powerpoint-style presentation) .mht looks good because it can retain original URLs of online resources, it's fairly human readable and debuggable, and it already has a standard and some support. An HTML document can reference its external parts (images, css) via either cid: URIs or the original HTTP URL as long as all the right Content-Location headers are present. a single compressed file (.zip?) looks good because of the size and how easily it can be unpacked and used with a browser that doesn't natively support the single compressed file. I don't know what URI scheme an HTML document would use to reference images and CSS. The only other thing I can think of is an HTML document that uses data: URIs to reference its external parts (e.g. a CSS file) which also use data URIs to reference their external parts (e.g. background images). What place does HTML5 have in specifying one of these options as a standard archive format? Any? A non-normative section on archives?
Re: [whatwg] Web Documents off the Web (was Web Archives)
On 4/16/07, Jon Barnett [EMAIL PROTECTED] wrote: RFC 2557 was mentioned in the last thread. http://tools.ietf.org/html/rfc2557 After reading it in detail (and indeed writing a script to send HTML with inline images as attachments), I quite like it. It's simple and obvious enough and allows for a fallback to a real internet URL if a corresponding URL exists. The main gripe about it was that binary data is base64 encoded, which adds size to the file in the end. A couple benefits to MHTML over ZIP are that HTTP headers are preserved and that the Content-Location header can directly associate a resource with it's Internet-hosted version, removing the need to change all the URLs (absolute or relative) in a document (and related documents, such as CSS files) to make it usable offline. zipping the final MHTML file could help with size. Considering that there's already a standard, the trick is getting browsers to support it. http://en.wikipedia.org/wiki/MHTML That pages tells a lot about what can save as MHTML but not enough about what can open and read MHTML. -- Jon Barnett
Re: [whatwg] Attribute for holding private data for scripting
If you want structured data in this attribute, why not just use JSON? That's an idea that crossed my mind as well. I dismissed it for a few reasons: - authors would have to entitize quotes and ampersands in their attributes, which they're not used to doing with JSON normally. - evaluating it would mean: var obj = eval(myelement.getAttribute(_myjson); which I don't like because I prefer to avoid eval at all costs. - it further marries HTML with JavaScript, which is something I'd like to see evolve and change in the future - something else widely supported, like client-side Python is a personal dream. Also, whatever attribute also needs to have meaning (read: be easy to get to in the DOM) when your document is processed by something other than a browser, such as PHP or Java. You, yourself, could still format your custom data that way, but I don't think it's a great idea to spec it that way. And I guess it's already been said that changing something in the DOM a good idea for this. We just want to allow authors to continue to do something authors already do without making validators complain. The idea of allowing just any attribute that starts with _ (or x_) has the best benefit - authors already do it, it's just a matter of making validators not complain.
Re: [whatwg] Attribute for holding private data for scripting
On 4/10/07, Sam Ruby [EMAIL PROTECTED] wrote: Instead of starts with x_, how about contains a colon? A conformance checker could ensure that there is a corresponding xmlns declaration that applies here, and possibly even do additional verification if it recognizes the namespace. An HTML5 parser would, of course, recover from references to undeclared namespaces, placing the entire attribute name (including the prefix and the colon) into the DOM in such situations. I like the idea of prefixed attributes for that purpose. This shouldn't be an issue for text/html parsing. http://www.whatwg.org/specs/web-apps/current-work/#attributes0 That section doesn't explicitly allow colons in attribute names. A provision would need to be made for that, but only for text/html parsing As for text/xml parsing, those prefixed attributes would need to belong to a namespace. Should there be a specific URI designated for these attributes - I suspect that allowing the author to make up his own namespace URNs whimsically is bad. Is there already a namespace URI for this purpose (e.g. urn:private)? Possibly causes more problems than it solves. What about any attribute that starts with _ as opposed to x_? I'm messing with designMode in Firefox right now, and it appears Firefox adds an attribute called _moz_dirty to certain elements for internal scripting purposes. Are there cases where other browsers do something similar? Is there already a convention in some applications similar to the -xxx- convension in CSS for this purpose?
Re: [whatwg] Attribute for holding private data for scripting
I can think of two possibilities.
One would be to allow the param element as a child of any element (or any
block level element?)
http://www.whatwg.org/specs/web-apps/current-work/#param
And then make an attribute of HTMLElement called params
readonly attribute HTMLCollection params;
Where params is a collection of HTMLParamElements that are children (not
further descendants) of that element.
That would make this:
div id=fooparam name=answer value=42Some more content/div
easy to access via JavaScript:
var foo = document.getElementById(foo);
if(foo.params['answer'] == 42) {
// it is!!
}
The only other possibility I can think of would be an HTML attribute called
params that would be a list of tokenized name value pairs, but that sounds
even hairier to implement.
This would have simplified something I did last week involving the Google
Maps API, where I did, as mentioned, make up a fake attribute. There may be
better ways to do this.
On 4/9/07, ddailey [EMAIL PROTECTED] wrote:
Henri, thanks for the link to PPK's suggestions -- I rather like many of
them.
Henri Sivonen wrote:
At http://www.quirksmode.org/blog/archives/2007/04/html_5.html PPK
suggests having an attribute for storing private data for scripts.
I'm having a hard time seeing what you're talking about here. When PPK
says
This attribute [to store data for unobtrusive scripts] should be valid
for
all HTML elements. I'm rather sure I've lost you.
Sometimes, I'll stick a long string inside an invisible textarea just so
as
to give JavaScript something to chew on -- then I can use string.split to
pull the data apart. Is that what you mean? I rather doubt it.
By private you don't really mean inaccessible to end users do you?
I think I need an example to understand.
regards,
David
--
Jon Barnett
