Re: [whatwg] Document with a single input[type=radio]?
On Thu, Apr 7, 2016 at 2:48 PM, Mikko Rantalainen < mikko.rantalai...@peda.net> wrote: > The spec says in 4.10.5.1.16 Radio Button state (type=radio) > > > > https://html.spec.whatwg.org/multipage/forms.html#radio-button-state-%28type=radio%29 > > "A document must not contain an input element whose radio button group > contains only that element." > > What this is supposed to mean in practice? Could this sentence be > dropped because this does not match real world browser behavior? > It means that you must have at least two radio buttons in the group. (A streaming browser will may hit this case after parsing the first > radio button element in the document. Then what?) > Nothing, because the document is not parsed yet.
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
I gave a limited one-page idea for now, so design faults should be obvious. This will take years, but right now it’s looking like there aren’t fundamental problems with the proposal. There are fundamental problems with your proposal, namely: 1) it relies on some undefined magic 2) it changes HTML to something entirely different. 3) you assume that those not willing to learn Javascript will somehow know how to use the features you propose without learning. How? That's obviously a horrible idea. Why would anyone encourage millions of other people to do more work? Everyone’s time is limited. Why should a fashion-blogger spend time to learn JS to get a responsive high-speed site? They have other things to worry about, like next season’s collections. The best experience should be on by default, and you need a built-in MVC framework in HTML for that to happen. And fashion designer will be able to use it without learning? Also it is not clear, how are you going to separate M from V from C if it is all HTML. You’ll find that the kind of proposal I’m putting out there is the only viable solution. Your proposal is just a bit of magical thinking, not any solution. I am not sure what problem are you trying to solve. Is that ‘allow non-technical people to build web-sites’? Then you are solving it at the wrong level. Best regards, Rimantas
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
There are fundamental problems with your proposal, namely: 1) it relies on some undefined magic I believe that’s called “programming”. So that poor fashion designer will have to learn to program after all… 2) it changes HTML to something entirely different. To what? HTML already has things like SCRIPT and other features not related to hypertext markup. I don’t know to what, I never saw any examples how your MVC would look like. Would you care to show how something like http://backbonejs.org/docs/todos.html would look if done your way? 3) you assume that those not willing to learn Javascript will somehow know how to use the features you propose without learning. How? They use HTML, which is far more widespread than Javascript. But they don’t do MVC with pure HTML. There’s a reason this proposal has gone viral outside of this list. Good luck. Best regards, Rimantas
Re: [whatwg] Hide placeholder on input controls on focus
On 2013 m. March 20 d., Wednesday at 03:20, Kit Grose wrote: In almost every case the placeholder remains visible until the user has begun typing, as I strongly believe it ought to be remain in the specification, since it provides the contextual hint for as long as possible. Agreed. In this case it also shows-up again if user deletes everything typed in, so you get reminded that the field is for without leaving it. Regards, Rimantas
Re: [whatwg] window.print() when printing is not supported
… On Linux I generally see a Print to File option when I try to print something, which lets me output to PDF and maybe PostScript. On Windows (at least Vista and later) I recall always seeing a print to XPS option. So on these platforms, it's *always* possible for the user to print, although not to a physical printer. So even if it were desirable to let the website know if the user can print, it's pointless, or pretty close. Print dialog on OS X also offers an option to save as PDF/PostScript and some more, depending on what applications you have got on the system. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] Use of p element inside the blockquote element
Previously in HTML 4.0 Strict and XHTML 1.0 Strict, any content inside the blockquote element had to be contained inside at least one p element. In these cases blockquote allows block-level elements (or script) elements as its children. So you can have Hx, DIV, table, lists, etc. in it. In HTML 5, that requirement appears to have been deprecated as the following element validates successfully: In HTML 5 content model for blockquote is flow content, that includes pretty much any element with textual content in descendents and the bare text itself as in your example. The current HTML 5 specification uses the p element in the usage examples, but does not mention whether it is required. For the sake of clarity, might I suggest that in the specification document there is a usage example of a blockquote element where a quote consisting of a single paragraph is included, but does not use the p element to contain that quote. Or, maybe a one-line explanation stating that the previous requirement of the blockquote element re. content being contained in a p, has now been loosened up. It is implied by content model for the element, I am not sure if more explict explanation is needed. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] framesets
OK and for clarity's sake I'll again repeat framesets don't solve the navigation problem, they just make it easier to solve than any other available proved solution, and this wee problem is that browsers own bookmarks, database users own database table rows, so usually you shouldn't bookmark database table rows, and much follows from that, therefore saying server issues don't bear on this issue is IMO astonishingly quite wrongly blinkered. How on Earth can you bookmark database table rows? Your database knows nothing where its rows go, the browser does not know where does HTML originates in: it may be DB, may be XML transformed via XSLT, may be static files on the server. All you can bookmark is some URL. On the server there must be an application, which maps that particular URL to this particular database row, retrieves it, transforms it into HTML and sends to browser. This application then is the right place to solve that bookmarking problem. It starts to look like you are trying to solve server side problems (restricting access, of whatever denying bookmarking is supposed to solve) via client side. Not going to work. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] framesets
Eh? He didn't say that; you're quoting me. I did, in fact, at least I meant that. Browsers own bookmarks, database users own database table rows, so it must be possible in database maintenance webapps to prevent bookmarking of elements which represent database table rows. And again, I agree that framesets do not by themselves block such bookmarking; they just make it easy to do so. Framsets do not make it easy. They make it harder to boomkark such URL, but in no way they make it easier for your app to block it. You still must to do all the logic on the server side. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] framesets
So it does not answer the question: if framesets are as you claim not needed for the full spec, there should be lots of non-frameset sites which meet this spec as efficiently as ours does. Maybe there are not many sites because nobody wants this type of sites? I hate this type of documentation sites personally. And to me this use case looks built around the chosen implementation, while I prefers solutions built around solving the real need. If that blocks a use case, by all means don't use a frameset for it. For this use, the above poses no problem at all. And if CSS were actually as efficient for this spec as framesets, surely some developers would have taken advantage of that by now. Once again you assume that your spec is highly desired. Maybe it is not the case and so nobody bothered. … No need in this case. … Not an issue for this use. So you want HTML5 spec tailored for this particular case of yours? Can I have dancinghampsters tag, please? Here's an application for framesets which is valid on previous versions of HTML, Nobody forbids you from using previous versions of HTML. meets a need, is more efficient than known implemented alternatives for this use case, You have framed (pardon the pun) this use case this way and reject all other options. Once again—you can use HTML4.01 frameset document with HTML5 documents loaded to frames. This was suggested more than once. and does not suffer from any of the frameset deficiencies you have listed. How so? Framesets remain useful, excluding them from HTML5 undermines support for those uses, and that weakens HTML5. I'd argue that it strengthens HTML5. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] framesets
Maybe there are not many sites because nobody wants this type of sites? You think nobody wants Javadoc? Javadoc has been shipping with an read-only version of this use case for years. Of course Java developers want access to documentation. I am not sure if they want frameset though. The full use case is treeview database maintenance. Server side should not be even mentioned in this case. Tree logic has been slow to mature in SQL, is non-trivial in HTML as we see, and is hard to generate from PHP/Ruby/whatever. Tree logic requires a bit of effort with table design and SQL, and is very easy in HTML and PHP/Ruby/whatever. … while I prefers solutions built around solving the real need. Which this is. Nope. I guess real need is something along the lines provide access to documentation online or something like that. … Nobody forbids you from using previous versions of HTML. Correct, but excluding frameset from HTML5 increases the likelihood that browsers will drop support for the feature. I would like to see that but not going to happen. Browsers will support HTML4 for decades to come. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] framesets
There are good database reasons to block bookmarks to table rows, so that must be doable. I still don't get what database has to do with it? block bookmars to table rows? Does it make any sense at all? … Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] framesets
Thanks for responding. Perhaps you can show me otherwise, but containing a browsable tree insided a fixed sidebar does not give us independently scrolling subwindows side by side on one page, with the possibility of editing in either subwindow without the slightest effect n the other. That is the requirement, framesets let us meet it, and nothing else we know of does. How about overflow-y:scroll? (PoC: http://rimantas.com/bits/cssscroll.html ). However I do not agree that this kind of navigation necessarily provides level of usability higher than any other method of presenting content of such type. (Of course even if it is possible to do it without frames, new standards ought not to require that perfectly functional, legal, working code be rewritten on pain of standards non-compliance.) New standards to not require anyone to rewrite anything. Older standards stay valid. Why not just use HTML4 with frameset DTD? … Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] HTML 5 Script Tag
No elements in text/html can be self-closing. Except of course for the following: area base br col command embed hr input img link meta param and source And these obsolete elements still supported by legacy UAs: basefont bgsound and wbr Except, of course, that these are not self closing. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] due consideration
The point I do not doubt of Ian's good faith, nor of his huge effort in making HTML5 the best possible thing it might be. However, I doubt of the sanity of having an individual to have the final say about any topic, I don't doubt the sanity of it at all. even above expert groups that have been researched and discussed the topic for years. That's that happen when no one has a final say: years of discussions. Quite often—about the color of the bike shed. Just because the fruit of so long work can't be properly sintetized in plain-text e-mails doesn't mean that there is not enough value on it. Going back to the example, there was a lot of people involved in RDF and RDFa since 1997. That's already twelve years of continuous work and research by several people. HTML5 replaces all this effort (RDF and RDFa) with that of a single person over few months (Microdata). I doubt that discussions started in 1997 with HTML5 in mind. So I guess those interested can keep going for 12 more years if so inclined. Honestly, I can't say for sure which method would be best for HTML; but I'm still convinced that having a single gatekeeper with absolute power over the next web standard is, at least, insane. I'd say that's the one the best ways to get something practical done. To quote Frederick P. Brooks Jr.: Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds — The Mythical Man Month, Chapter 4 Aristocracy, Democracy and System Design Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] Make quoted attributes a conformance criteria
However, the quotation marks being *sometimes* optional is quite dangerous, since an author needs to exactly remember when they are needed and when they aren't; and using always quotation marks does avoid this problem. If author does not remember he can always use quotes and avoid this problem. I like the idea of having option to omit quotes valid for those who remember. Again, the point is not that *sometimes* it is safe to omit the quotes. The issue is with remembering when it is safe and when it is unsafe. I think you overestimate the danger. So my vote is against such a requirement. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] ---
... The emphasis of the HTML5 spec (but also the XHTML2 and HTML4) lies on the browser part. I understand, after all that is your job and I am sure you are all very capable of that. But please, let the actual markup language itself be defined by others who are more capable of doing that. Thanks for the laugh, indeed. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] keygen element
... For those of you who doesn't know what this element is doing; Its for generating a private/public certificate keypair. The browser keeps the private one, and the server gets the public one which it signs and then sends back to the browser. This is extremely useful for secure verification. Netbanks and other heavy security sites should/are using this. ... Is there any hope for this element? What information does which people want to make this an HTML5 standard? Hi, how is this better than SSL/TLS? Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] window.opener and security
2007/3/20, Gareth Hay [EMAIL PROTECTED]: window.opener should be read-only and attempting to write to it should throw an exception. It was possible to set window.opener in IE, alas, I do not remember which version :( But it has been fixed, AFAIK. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] several messages about HTML5
... 10. In the minds of most people, HTML is dead and X/HTML 5 is perceived as an attempt to resurrect it. Given this perception, how can you succeed in marketing HTML to consumers (those who build Web sites)? Aren't those minds of the people who sell XHTML tools with false statements like This is because only XHTML Strict and 1.1 guarantee the clean separation of data from formatting, making them the clear choice whenever availability of data is an important factor.? From what I see around most people don't really care is it XHTML, HTML or FOOBARML, as long as it works. Some of those who do realize that HTML4.01 might be better idea than XHTML processed by HTML parser... HTML5 might be very appealing excatly because it is as close to the real world (tm) as possible. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] The m element
2007/2/8, Anne van Kesteren [EMAIL PROTECTED]: ... I think I agree that m should be dropped. ... +1. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] blockquote cite and q cite
/me creates HTML 6.0 Just 4 elements html, div, span, a and a few attributes. class, href, title, id, rel, etc Human audience will be satisfied. A lot simpler to type. For the rest it is just a question of css and appropriate class. I would like to have role and about though, and I'm satisfied. Useless semantics [Henri Sivonen (c)] defined by profiles with values of attributes. Cannot html element be dropped safely? And one of the div-span pair should go. I have mixed feelings here - div is shorter, but span looks more apropriate: it can span a word, or it can span a paragraph... So in HTML6.1 we are left with span and a. All the mess was moved to class and rel attributes :) And sincerely I do not think the addition of elements will solve many things for HTML. Agrred. But this is very very tough problem - where to draw the line. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?
Indeed, and, from the broad indications they do give, there's /nothing/ to suggest that they favour conformant markup over non-conformant markup: Currently we take into account several factors, including a given page's simplicity, how much visual imagery it carries and whether or not its primary purpose is immediately viable with keyboard navigation. There are some relevant advices at http://www.google.com/support/webmasters/bin/answer.py?answer=35769 too. They don't mention accessibility and are oriented towards betters position at SERPs, nonetheless: Make sure that your TITLE and ALT tags are descriptive and accurate.; Check for broken links and correct HTML. ;Use a text browser such as Lynx to examine your site, because most search engine spiders see your site much as Lynx would. If fancy features such as JavaScript, cookies, session IDs, frames, DHTML, or Flash keep you from seeing all of your site in a text browser, then search engine spiders may have trouble crawling your site. These won't hurt accessibility either. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?
Make sure that your TITLE and ALT tags ... Tags... Right. ha ha, good catch, how did I miss this one... Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] XML databases, XML syntax and HTML5
... I understand why relational databases were used to build blog engines and content management systems. For a long time that was all we had. However, that's going to change fast. I expect that new systems are going to be developed using pure and hybrid XML databases like Exist and DB2 9. The advantages to a programmer working on such systems are just too compelling to ignore. Or maybe programmers use these database systems because they work, and work good enough? One consequence of building on top of native XML database rather than a relational database is that well-formedness is going to become more important, not less. In fact, well-formedness is going to become essential because these systems cannot store anything less than a fully well-formed XML document. I predict that this, if nothing else, is going to convince blog engines and content management systems to start fixing up malformed content before storing it. Maybe all the legacy systems won't convert, but the new ones most certainly will. In other words this means, that John Doe will have more headache with such system, which will be pretty compelling reason to stick with old-fashioned RDBMs which just work. In short - I don't share your vision of the bright future of XML DBMS. Time will show. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?
2006/12/1, Ian Hickson [EMAIL PROTECTED]: ... An example of something that is NOT implemented interoperably is script src=.../. As far as I can tell, script/ is handled by all browsers the same way as script. How is it not interoperable? That's true, however, what happens depends on the browser and presence of /script in the code. When IE encounters script type=text/javascript src=somescript.js / it swallows everything after as the content of script. If there is no /script in the source - that's it. Firefox likes consistency: script type=text/javascript src=somescript.js / works OK, This is OK too: script type=text/javascript src=somescript.js / psome text/p script type=text/javascript src=somescript2.js / However script type=text/javascript src=somescript.js / psome text/p script type=text/javascript src=somescript2.js/script Produces only single SCRIPT in DOM tree swallowing paragraph and the second script. Opera handles the last example just fine. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?
... The trailing slash issue should be inexistent. Today many sites use this trailing slash in HTML pages. Even if those pages do not validate today, I consider they should validate, as long as they validate without the trailing slashes. ... I don't think that page claiming to be authored as HTML4.01 should validate if it contains br /, etc. which, at least in theory, has entirely different meaning. Another point, maybe a bit off-topic: http://annevankesteren.nl/2005/11-kurafire ;) Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] img element comments
* The height and width attributes as defined are completely
presentational. I don't really see any value in keeping them. Now I
suppose they have to be supported anyway, but so does body bgcolor=.
I disagree. Specifying the size is very good for incremental rendering,
but the alternatives are awful.
+1 on that.
1. img ... style=height: 100px; width: 100px;
The style attribute is far more presentational than the height and width
attributes.
2. img ... id=foo
#foo { height: 100px; width: 100px; }
This is simply not feasible in most cases, unless there are very few
images on the site. Think about flickr, it just wouldn't be possible to
specify the dimensions of all their images in a stylesheet.
Another thing is that with height and width attributes information
about image size is
available at once, when in case of CSS it is available only after
stylesheet file is loaded
and parsed.
As for style=... I wish there wasn't such thing...
Regards,
Rimantas
--
http://rimantas.com/
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
... To get valid markup I must use a table tags if I want my layout to *function* that way. There is no way to fake it. It took three minutes to change the tags to table tags and the page functions perfectly now. This is for the benefit of the users. Some case of non sequitur, imho. I am in ban tables for layout camp. If anyone want to use them for this purpose they are free to use some other standard or do not use any standard at all... Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] modal and modeless windows
On 6/27/05, Karl Pongratz [EMAIL PROTECTED] wrote: ... Beside that, how many desktop applications do you know which don't use modal and modeless windows? ... The fact that some applications use modal windows does not necessarily mean that it is a good idea. In fact, all the books I've read on interface design say that modal windows are bad idea. At least they are used mostly in the bad way. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] modal and modeless windows
On 6/27/05, Karl Pongratz [EMAIL PROTECTED] wrote: ... In most cases, if you show me an application with a modal window, I'll show you an application that needs to do away with a modal window. The use cases for applications that truly need modal windows probably overlaps the use cases for XULRunner-base applications quite nicely. That's new to me. Can we live without modal windows from now? Is that somewhere written? ... Not exactly this way, but you may want to check: Chapter 10 Eliminating Excise Chapter 11 Navigation and Inflection Chapter 30 Using Dialogs Chapter 34 Notifying and Comfirming in About Face 2.0 The Essentials of Interaction Design by Alan Cooper Robert Reimann, Willey Publishing, 2003 6-5 Letter from a User in The Human Interface - New Direction for Designing Interactive Systems by Jef Raskin, Addison-Wesley, 2005 Also the classics: Design of Everyday Things by Donald A. Norman and Inmates are Runing the Asylum by Alan Cooper won't hurt :) Regards, Rimantas -- http://rimantas.com/
