Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
I was under the impression that the brackets were part of the host syntax,
but a_Url_hostname() shows that they are part of the _authority_ and are
stripped out when making the hostname.
|
|
|
|
|
|
Basically, I and i are different letters in Turkic languages, and this
causes problems for str(n)casecmp and toupper/tolower in these locales
when dillo is dealing with ASCII.
|
|
|
|
|
|
|
|
|
|
I'd asked furaisanjin about input methods, and it sounded like it would be
okay, but it turns out that something goes wrong on his system after all
(LANG and the various LC_* set to ja_JP.eucJP normally, "while converting
to Kanji, font width is half and it's not easy to recognize.")
So I can't get away with the lazy fix after all.
|
|
copied from history callback, of course
|
|
|
|
The standard solution to I and i being different letters in Turkic
locales is to make your own ASCIIfied strcasecmp/toupper/tolower,
but I'm not aware of us currently having any need/use for non-C
LC_CTYPE.
|
|
bug #1018 submitter requested behaviour a little more
friendly to html5, which sounds sensible as bits of
that infinite monstrosity start showing up more
often...
|
|
|
|
the value of the property is inherited, and might not be 'normal'
|
|
effect
Using roughly 1.2 per step, a value mentioned in the CSS2.1 spec. Firefox
appears to use a value that is similar but a little larger.
http://css-tricks.com/2580-css-font-size/ says that "keyword sizing is
pretty consistent across browsers and platforms", and perhaps someday
we'll want to go out of our way to make them exactly the same, but this
is a start.
|
|
field ordering
found by furaisanjin.
|
|
found by furaisanjin.
http://www.rfc-editor.org/errata_search.php?rfc=2617 has an entry
showing that this should be done. Now, the RFC was done in 1999, and
the error was reported in 2010 and verified in 2011, so we're lucky
with our timing, but isn't it surprising how slow of a process it is
to clean out the corners like this in important specifications?
|
|
found by furaisanjin.
My reading of rfc 261[67] is that this whitespace is fine. But easy enough
to take out...
|
|
|
|
|
|
Justus contributed the original patch in April 2009.
I read RFCs, fixed bugs, restructured, tested.
|
|
|
|
|
|
Use the name from rfc2616 to make it easier to understand
|
|
Topic brought up by Alexander recently. In FLTK2, Enter and Space would
both trigger buttons. In 1.3, only Space does it. I asked the FLTK guys
about this, and I learned that Space to trigger buttons is actually
old-school X behaviour that I somehow never became aware of.
|
|
|
|
I accidentally went to the url "80", got an unfamiliar error msg, and
immediately wondered what valgrind would think of this unfamiliar path.
And valgrind found a bug.
|
|
as suggested by Axel Beckert in
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-September/008992.html
|
|
|
|
|
|
Trying to make it a little clearer. It's surprising how there isn't
a good, brief, clear term for this. Discussion of the concept tends
to start using words like "administration" and "control".
|
|
|
|
|
|
|
|
|
|
It looks like plastic just _insists_ on mixing lots and lots of grey in,
so if you pick a color that you like in plain/gtk+, it gets seriously washed
out in plastic. There is a problem of getting nearly indistinguishable
colors.
|
|
|
|
|
|
What an awful situation it is in general.
|
|
|
|
as mentioned in section 7.1 of RFC 6265
|
|
|
|
as mentioned in section 7.1 of RFC 6265
|