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 whos
> > 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
> 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 cha
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 t
<…> 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,
> Previously in HTML 4.0 Strict and XHTML 1.0 Strict, any content inside
> the element had to be contained inside at least one
> 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, t
> 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
> 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
> book
>>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
> 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 documentati
> 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/
> 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
>> No elements in text/html can be self-closing.
>
> Except of course for the following:
>and
>
> And these "obsolete elements" still supported by legacy UAs:
> and
Except, of course, that these are not self closing.
Regards,
Rimantas
--
http://rimantas.com/
>
> 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 r
> 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 pro
<...>
> 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.
<...>
> 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
> verific
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/
<...>
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
2007/2/8, Anne van Kesteren <[EMAIL PROTECTED]>:
<...>
I think I agree that should be dropped.
<...>
+1.
Regards,
Rimantas
--
http://rimantas.com/
So in HTML6.1 we are left with span and a.
If you're going that far, why keep ? is clear enough.
One element to rule them all, one element to...never mind.
Hmm... To paraphrase one saying: every markup language can be reduced
by one element, and in every markup language there is at least one
el
/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
> "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/
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
<...> 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. Th
<...> Apparently Apple, Mozilla and
Opera have that ambition. Smaller ones, like iCab and lynx, will just have to
follow. But what about Microsoft? I still have the impression that they can
undermine this entire effort by getting people to use authoring tools that on
purpose contain errors that r
<...>
P.S. That script, complete with indentation and readable variable
names, is still an order of magnitude smaller than
http://whatwg.org/images/logo
<...>
And so is this one: http://rimantas.com/bits/whatwg.png
I get your point, but that image could use spome optimisation...
Regards,
2006/12/1, Ian Hickson <[EMAIL PROTECTED]>:
<...>
> An example of something that is NOT implemented interoperably is
> .
As far as I can tell, is handled by all browsers the same way as
. How is it not interoperable?
That's true, however, what happ
<...>
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 a
>> * 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 .
I disagree. Specifying the size is very good for incremental rendering,
but the alternatives are awful.
<...>
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
<...>
You are also free to write the booklet "Dialogs for dummies", where you describe
for the world of legacy software developers why the concept of a transaction
point
which is a core facility in a database system, should not have a GUI
counterpart.
<...>
Chapter 30 "Using Dialogs" in "Abou
