This repository has been archived by the owner on Jan 5, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
designNotes.txt
126 lines (85 loc) · 7.37 KB
/
designNotes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
***11 oct 04 Comment by D:
Today I found that the support for the CSS3 columns layout module is implemented on the trunk. Here is what the HTML could look when it lands on the branch. It would be much easier to generate and I'm not sure, but maybe we could build a simple DOM tree from the RDF bookmark source and then generate the page with XSLT transform.
JE: eh.. xslt? I'm learning a lot lately :-). Since it's not even available yet for the latest mozilla/firefox releases, I suggest that, at least for the next version of bmh, we are not going to do something with this.
I think it will speed up the code and give us more flexibility.
Pros:
1. The template would be encapsulated in separate file and changes to the template won't require changes to the generator code.
2. We could easily have multiple custom templates, though they would be more complicated to write than the custom styles.
3. I guess that the XSLT processing is done by C code, while the string concatenation is much slower. (At least I Mozilla renders XML + XSLT documents pretty fast.)
Cons:
1. In case we implement the FTP functionality the uploaded pages won't be able to render with columns when viewed with other browsers (do we care about this?)
JE: Yes, when you're in some other place than at home, it is unlikely that mozilla is available
2. Styling becomes even more flexible (read complicated.) We can try to solve this problem by having two stylesheets - 'base' defining the layout and using the system colors; and 'custom' defining user colors and tweaks.
3. The columns layout seems to have problems with hovering over non-link elements. Will investigate further.
Possible Implementation:
1. If the timestamp of bookmarks.html is earlyer than the one of the cached HTML file, goto 5
JE: bookmarks.html is created when mozilla exits. So any changes made to the bookmarks in between start and exit won't come through
2. Get the DOM tree either from the RDF datasource or from the bookmarks.html file.
3. Apply XSLT transform.
4. Serialize the resulting DOM to temporary HTML file.
5. Display the cached HTML file with stylesheet using the new -moz-column-count property.
I've attached a prototype of the static html+inline style (have stripped the JS). To test, download latest trunk version and open the file. In mozilla browsers not-supporting the columns layout, it looks like single column. In any other browser looks like crap (could do something about it.)
*** 10 oct 04 Comment by JE:
Since users can only change the layout by adapting the stylesheet, we should make all stylesheets as uniform and as easy to edit as possible. A few suggestions to start with:
- colors only in hex format with 6 figures (not 3) and lowercase
- relative values for font size only (em no px)
- readible and uniform indentation
*** 09 oct 04 Comment by D:
I think that XHTML is a good choice, since it's
more rigid, so it should parse faster (right now my bookmarks page takes
about 3-5 secs to show up.)
JO:
I agree about XHTML.. although I think the reason for the slowness is
the javascript.. what would be awesome is if you could create a static
HTML file, that would be updated every time the bookmarks change.. that
way it wouldn't have to be generated by javascript, and would be tons
faster.
JE:
I think 3-5 seconds is very long! How about on your machine Josh? I think, like Josh, that the javascript is the cause (which you can easily try by loading the static page and time how long it takes). Creating a static page that updates is to impractical. Either you'd have to rewrite the entire file for every minor change, or you would have to do it at regular intervals.
*** 09 oct 04 Comment by JO
is there any way we could use layers (div tags) instead of tables?
D:
The problem with the diffs is that right now there's no way to specify
columns. You can use floating difs but then the layout is f*ed when they
dont fit the width of the screen and got wrapped to the next 'line'. If
we take this approach, we could cut everything above the folder div's,
but then if you have one folder with 100 items and next to it one folder
with 3 items, both would occupy the same vertical space (which IMHO is
not nice.)
On the other hand there might be another approach that I can't think of
now (I heard something about columns prop in CSS3, but I guess it's not
supported ATM.) So you are welcome to experiment :-) For now, the most
important is to get nice static page which can be flexibly styled and is
standards compliant.
JO:
I guess you are right.. tables would be best as of now, although I have
heard of people making tabular layouts using DIVs.. its just a little
hard :)
JE: A table it shall be
*** 09 oct 04 Comment by D:
-- CHANGES to bmhX.htm -- -- -- --
Well formedness violations:
All elements must be properly closed. (this is different than HTML when some elements like meta or link must not be closed)
Offending: meta, input
Structural violations:
The inline elements can not contain block elements. See the XHTML DTD for allowed nesting. If you use some editor with DTD support it would make it easier (I use Eclipse with the XML Buddy plugin.)
Offending: a should be inside of h1
Content violations:
Each form must have a target attribute. We could use it to handle a the form action instead of the onclick handler.
The name attribute is an alias for id. See http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_nameidentmodule
Though in HTML you can stick in whatever you want, XHTML doesn't allow this.
Also, XHTML requires all URLs to be wellformed according to RFC2255, so in general we should avoid the complex javascript URLs and use simple function calls where possible. In fact I cannot think of situations where it's not possible. See the 'target' attribute of the form for example of correct URL escaped javascript (fugly ugh?)
As far as I can see, we put the description of the folder in the name attribute of the bookmark links. We cant and shouldn't do that. Right now I'm putting it into the title attribute of the folder link, still if we need to display it for each BM link we can put it in hidden span which would be shown on mouse hover of the parent link.
Since the javascript urls in the title link broke the XHTML, I moved the handling to onclick handler and put the function in the head (later we can move it to the lib if we all agree on it.) I also added empty href attribute, to keep the titles looking as links, though I'd prefer to drop it and do the styling with CSS.
*** 7 oct 04 Comment by D:
The majority of the URLs are not chopped off (at least at my bookmarks list.) Perhaps we could
use some rules, like:
1. when the displayed name is chopped with more than 25%, force the
title to be the bookmark name.
2. if there is a description, use the description
3. use the name
I'm not sure if my suggestion is ok, my point is that for some bookmarks
I enter shorter names and put the description into.. the description
field.
JE: I never use descriptions. I'd like to have both the name and the description (if there is one), seperated by a newline, but mozilla displays newlines as a vague square. Can anything be done about this with css? Josh, if you have an opinion about this, speak out!
JO: I too don't use discriptions, I think its fine as-is.. if you don't lite them getting "chopped off" you could increse the length before it is truncated, or, you can rename all your bookmarks with shorter names (thats what I did)